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ABSTRACT 


Maintaining an information advantage for the Department of Defense (DoD) and 
its military departments is critical to national defense objectives and the 
acquisition of new information technology (IT) is key. The DoD seeks to quickly 
acquire IT systems that meet requirements and are within budget; however, this 
goal has been very difficult to achieve given the cumbersome and deliberate 
process through which IT systems have been acquired. Essentially, the DoD’s 
acquisition process cannot keep pace with the rapid development of IT systems 
that occurs in the commercial sector. For years, the DoD has relied on a common 
approach in acquiring different systems and services. This approach has been 
laced with inefficiencies and inadequacies that have resulted in prolonged 
schedules as well as increased cost. Currently, the DoD is implementing a new 
IT acquisition process; however, this new process does not resolve all the issues 
that have plagued IT acquisition. This study will identify the causes or impeding 
factors that have prevented the DoD from acquiring new IT systems in a timely 
manner and will recommend alternative solutions to solving the problems. 
Ultimately, this thesis contributes to the DoD’s efforts to resolve the issues that 
continue to undermine timely IT acquisition. 
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I. INTRODUCTION 


A. INFORMATION TECHNOLOGY ACQUISITION WITHIN THE 

DEPARTMENT OF DEFENSE 

The Department of Defense (DoD) has leveraged information technology 
(IT) extensively in order to build national security systems, business systems, 
and weapons systems in the interest of National Defense objectives. The DoD 
continues to invest in IT capabilities and will continue to rely on IT systems in 
order to meet the challenges of twenty-first century warfare. IT acquisition is 
generally defined as the act of acquiring or gaining new technologies in order to 
meet a specified requirement and the Defense acquisition system is the method 
used by the DoD to acquire these new technologies. For the DoD, a successful 
IT acquisition project is defined as a project that is delivered on time and on 
budget with the required features or functions that are of the current IT product 
generation or current with regard to commercially available systems (Gansler & 
Lucyshyn, 2012). 

The DoD seeks to acquire IT systems that meet requirements quickly and 
cost effectively; however, this endeavor has been very difficult to achieve given 
the cumbersome and deliberate process though which IT systems are acquired. 
Moreover, the traditional acquisition system cannot keep pace with the rapid 
development of information technology systems that occurs today. In 2009, a 
major study conducted by the Defense Science Board (DSB) concluded that the 
traditional DoD acquisition process, as described in DoD Instruction (DoDI) 
5000.02, is too long and too cumbersome to meet the needs of the many IT 
systems that require continuous changes and upgrades (DSB, 2009). 

For years, the DoD has relied on a common acquisition method, or a one- 
size-fits-all approach, for acquiring different systems and services. This singular 
approach has been laced with inefficiencies and inadequacies ranging from 
requirements generation and funding to oversight and management issues, all of 
which have contributed to prolonged schedules and increased cost. It is critical 
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that the IT acquisition process be improved in order to increase the effectiveness 
of employing new systems to meet requirements in a timelier manner. The DoD 
has earnestly made several attempts to revamp the acquisition system to 
decrease the acquisition cycle time; however, it appears that these changes have 
had little impact because the timeline remains long compared to the commercial 
sector. Commercial technology evolution cycles for new IT systems average 
12 to 18 months but fielding of useful IT systems within the DoD can take an 
order of magnitude longer. For instance, a House Armed Services Committee in 
2010 found that the delivery of systems required between 48 and 60 months 
(HASC, 2010). This is problematic since the commercial IT acquisition process 
takes approximately one-fifth of the time it takes the DoD, which results in the 
DoD’s new IT systems being outdated even before they arrive to the end users. 
Therefore, the DoD has begun to implement a new IT acquisition process for IT 
systems designated as Defense business systems (DBS). This new IT 
acquisition process is referred to as the Business Capability Lifecycle (BCL) and 
it is considered a first step in responding to a congressional mandate to employ a 
new system. However, BCL does not resolve all IT acquisition issues due to 
shortfalls and potential problems such as its applicability across all IT 
acquisitions and funding methods used to acquire IT. 

It is clear that the DoD intends to improve the IT acquisition system in 
order to acquire IT systems in a more timely manner, but what is unclear is how 
the DoD will do so, especially in the wake of projected defense budget cuts. This 
thesis will discuss the causes or impeding factors that prevent the DoD from 
acquiring new IT systems in an expeditious manner and will recommend 
alternative solutions to solving the problems. Also, this thesis will include a 
historical perspective of acquisition reform, a systematic look at the entire 
acquisition process, an analysis of the value of proposed solutions, and 
organizational change management theory as it relates to implementing new 
processes and procedures such as the new BCL IT acquisition process. 
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B. PROBLEM STATEMENT 


This thesis seeks to address the DoD’s acquisition process for acquiring 
new information technology (IT), which has been inadequate in keeping pace 
with the commercial industry’s production of new technologies. This is a problem 
because as the IT acquisition cycle time increases, so does cost; but more 
importantly, benefits are slower to be received by the warfighter or the end-user. 
As a result, newer and potentially better technologies always are available first in 
the commercial industry and perhaps even to our adversaries. 

C. PURPOSE STATEMENT 

The purpose of this thesis is to explore and understand the issues 
involved in the DoD’s acquisition process for information technology (IT) in order 
to recommend a new acquisition approach or solutions that are more conducive 
to keeping pace with the rapid IT development cycle found in the commercial 
industry. This study is important because the DoD increasingly depends on IT 
capabilities and IT is viewed as a capability that will provide the military with a 
competitive advantage in achieving information dominance. 

D. POTENTIAL BENEFITS 

The potential benefits that may result from this thesis are a better 
understanding of the problems within the DoD’s IT acquisition system in order to 
offer feasible solutions or recommendations for resolving the problems. This 
thesis contributes to the DoD’s efforts in resolving the issues that continue to 
undermine timely IT acquisition. DoD acquisition stakeholders could benefit from 
this research, as new approaches to the acquisition process will be explored. 

E. RESEARCH METHODOLOGY 

Several studies conducted since 2009 have warned of IT acquisition 
problems in regard to acquisition cycle-time, flexibility, and efficiency, and 
recommended reform efforts and improvements (e.g., development of a separate 
IT acquisition process). This thesis conducts a meta-analysis of this previous 
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research to identify common elements and acknowledged deficiencies in an 
effort to recommend further solutions. 

F. BACKGROUND 

In an effort to understand the significance of the IT acquisition issue 
before delving into the problems, the remainder of this chapter will present 
background information. This background information will provide an overview of 
the IT environment within the DoD, an explanation of the importance of IT within 
the Department as it relates to strategy, and it will provide an introduction to 
acquisition policy and the stakeholders involved. 

1. Overview of the Information Technoiogy Environment within 
the DoD 

a. DoD Dependence on Information Technology Systems 

Information technology (IT) has become ubiquitous across the 
Department of Defense (DoD) with a disparate set of uses and users. IT systems 
are used for a wide variety of purposes within the DoD forming an “information 
enterprise” as defined in DoD Directive 8000.01: 

[The DoD Information Enterprise consist of] information resources, 
assets, and processes required to achieve an information 
advantage and share information across the Department of 
Defense and with mission partners. It includes: (a) the information 
itself and the Department’s management over the information 
lifecycle; (b) the processes, including risk management, associated 
with managing information to accomplish the DoD mission and 
functions; (c) activities related to designing, building, populating, 
acquiring, managing, operating, protecting, and defending the 
information enterprise; and (d) related information resources such 
as personnel, funds, equipment, and IT, including national security 
systems. (DoD Directive 8000.01,2009) 

Information is the key enabler of the Defense Enterprise as was identified 
specifically in the 2008 National Defense Strategy (NDS, 2008). The DoD and its 
military branches have taken full advantage of the capabilities afforded by new 
information technologies. The U.S. military, in particular, has been enhanced in 
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its capabilities due to the profound advances in IT for weapons systems. Among 
other things, the DoD has greatly benefited in the areas of management and the 
overall operations of the Defense Enterprise. To gain these important 
capabilities, a significant portion of the DoD budget is spent each year on 
acquiring these relentlessly advancing technologies in order to support a broad 
range of warfighting and functional applications (NRG, 2010). The ability of the 
DoD and its industry partners to harness and apply advances in IT for command, 
control, and communications; logistics; and transportation has contributed 
enormously to making the United States’ military the best in the world. 

So pervasive is IT that it has become an essential part of the U.S. 
National Defense Strategy. From infrastructure to business systems to IT 
embedded in weapons systems, the DoD is completely dependent on information 
technology. While the importance of IT continues to expand, the information 
technology environment is experiencing disturbing trends that have exacerbated 
the issues within the IT acquisition process. Figure 1, taken from the 2009 
Defense Science Board Report on IT acquisition, depicts growing trends within 
the information technology environment that show an increase in IT complexity, 
foreign supply, vulnerabilities, threats, and cost with an associated decrease in 
the supply of U.S. computing graduates and qualified expert government staff 
(DSB, 2009). This occurrence is considered a “perfect storm” in regard to 
information technology acquisition because it further exacerbates IT acquisition 
issues. Additionally, as these issues occur, the rate of technology change 
continues to increase as well as the interconnectedness of systems, which pose 
additional risks for the DoD. 
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Figure 1. The Perfect Storm (From DSB, 2009) 


b. Information Technology as Defined by the DoD 

For the purposes of this study, it is important to understand how the 
DoD defines information technology. Over the years, information technology has 
been defined in slightly different ways. As it is defined in the 1996 Clinger Cohen 
Act, formerly known as the Information Technology Management Reform Act, 

the term “information technology”— 

(A) with respect to an executive agency means any equipment or 
interconnected system or subsystem of equipment, used in the 
automatic acquisition, storage, analysis, evaluation, manipulation, 
management, movement, control, display, switching, interchange, 
transmission, or reception of data or information by the executive 
agency, if the equipment is used by the executive agency directly or 
is used by a contractor under a contract with the executive agency 
that requires the use— 

(i) of that equipment; or 

(ii) of that equipment to a significant extent in the 
performance of a service or the furnishing of a product; 
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(B) includes computers, ancillary equipment (including imaging 
peripherals, input, output, and storage devices necessary for 
security and surveillance), peripheral equipment designed to be 
controlled by the central processing unit of a computer, software, 
firmware and similar procedures, services (including support 
services), and related resources; but 

(C) does not include any equipment acquired by a federal 
contractor incidental to a federal contract. (Clinger Cohen Act, 

1996) 

This definition outlines IT in its broadest sense. IT can be generally defined as 
any system or subsystem of hardware or software whose purpose is to acquire, 
process, store, or communicate data or information (DSB, 2009). Also, IT can be 
defined as those systems that support the DoD information enterprise, especially 
those systems expected to run on or interface with existing infrastructure, 
systems that are user-facing, and is limited to those that are delivered through 
the acquisition process and not systems developed by individual commands 
(DSB, 2009). For the purposes of this study, IT is defined as any computer 
hardware or software system whose purpose is to acquire, process, store, or 
communicate information. 

c. The Rapid Advancement of Information Technology 

The DoD has not been able to keep pace with the rapid 
advancement in IT due to the ineffectiveness of the IT acquisition system. 
Information technology, both software and hardware, continues to rapidly 
advance as postulated in 1965 by Gordon E. Moore, co-founder of Intel. Moore 
(1965) predicted that the number of transistors on an integrated circuit board 
would increase at a rate of roughly a factor of two per year; he later refined his 
projection to a doubling every 2 years (DSB, 2009). This happening is referred to 
as Moore’s Law. Moore’s Law describes an exponential growth in technology 
advancements in such areas as computer processing speed and memory 
capacity. For example, software and hardware have advanced at a very fast rate 
over the past several decades, from isolated standalone computing systems in 
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the middle of the twentieth century to networked systems that span the globe 
today, these IT advancements have been transformational. 

With rapid technology change, we are experiencing a rapid global 
increase in connectivity among computers and, consequently, among people 
(DSB, 2009). Also, the spread of information technology has shifted the roles of 
citizen and state. New information technologies such as mobile devices and 
cheap digital storage devices have provided individuals and groups with 
unprecedented capabilities to organize and collaborate in new ways. Moreover, 
the Internet, social networking, on-line search engines, video teleconferencing, 
and multimedia-enabled smart-phones are but a sample of IT-based capabilities 
that have altered the ways in which people communicate (NRG, 2010). The 
capability the DoD possesses through information technology is apparent and its 
uses have never been more significant. In fact, DoD IT systems cover a broad 
range of diverse technologies, domains, missions, and customers. This broad 
range includes support to National Security Systems (NSS), operational 
processes, and infrastructure (see Figure 2). 


Intent 


Customer 



Figure 2. DoD IT Framework (From DSB, 2009) 
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2. Importance of Information Technology to the DoD 

a. The Advent of the Information Age and Information 
Revolution 

The Information Age and the Information Revolution have brought 
with it a plethora of personalized products and services and a powerful 
combination of centrally supported IT and end-user-driven IT, which have 
changed how we as a nation do business. This has resulted in an empowerment 
of individuals and organizations, giving them the ability to innovate their technical 
capabilities and their business processes (NRG, 2010). At the same time, the IT 
revolution of the past 20 years—everything from hardware and software, data 
standards, and commonly agreed-upon architectural frameworks—has 
completely permeated the national security enterprise. Like the business world, 
the DoD runs on information and seeks to gain an information advantage. 
Information technology systems not only underpin the business practices and 
management of the Department, but they have become integral to advanced 
weapons systems such as laser-guided munitions and global positioning devices. 

The importance of information technology to military capability is 
inestimable. IT has enabled nearly all of the military’s combat capability and has 
become a necessary element of critical warfare systems, warfare support 
systems, and Defense business systems. This study focuses on IT acquisition as 
it relates to Defense business systems (DBS). The term “Defense business 
system” is defined as an information system, other than a national security 
system, operated by, for, or on behalf of the Department of Defense for activities 
such as acquisition, financial management, logistics, strategic planning and 
budgeting, installations and environment, and human resource management 
(USD[AT&L], 2008). The designation of “business system” may give the 
impression that these systems only relate only to administrative-type operations; 
however, these systems have a direct impact on warfighting capability. For 
instance, all military operations are inherently dependent on logistics support 
systems, and, consequently, the business systems that support logistics 
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functions are considered Defense business systems (Gansler & Lucyshyn, 
2012). Also, IT plays a significant role in national security systems. According to 
the Clinger Cohen Act of 1996, a national security system is defined as: 

A telecommunications or information system operated by the 
federal government, the function, operation, or use of which: 

(A) involves intelligence activities; 

(B) involves cryptologic activities related to national security; 

(C) involves command and control of military forces; 

(D) involves equipment that is an integral part of a weapon or 
weapons system; or 

(E) is critical to the direct fulfillment of military or intelligence 
missions. Does not include a system to be used for routine 
administrative and business applications (including payroll, finance, 
logistics, and personnel management applications). (Clinger Cohen 
Act, 1996) 

Thus, national security systems include satellites, missiles, tanks, ships, and 
planes where IT is embedded within the system. IT touches a wide range of 
Department systems and, in turn, enables a wide range of capabilities. 

b. Information Technology as it Relates to Military Strategy 

Technological advancements have created a new world for military 
operations. This new world began to take shape at the turn of the century when 
the DoD developed a military transformation strategy referred to then as Network 
Centric Warfare (NCW). The IT acquisition is important to NCW strategy because 
the strategy relies heavily on information technology being available. 
Furthermore, the net-centric strategy is a capability that provides the DoD with a 
competitive advantage, which is essential to conducting twenty-first century 
warfare in the Information Age. This new strategy was important to DoD’s 
transformation into the Information Age and remains important today. To gain an 
appreciation of the significance and the urgency of solving IT acquisition issues 
within the DoD, it is necessary to understand why IT is so important to the 
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Department and how an effective military strategy is closely tied to an effective IT 
acquisition system. 


c. The DoD’s Net-Centric Strategy 

In the late 1990s, the Department of Defense (DoD) began a force 
transformation initiative in order to advance the military into the Information Age. 
This initiative was facilitated by the advent of new technologies and the need to 
achieve information superiority against an adversary. The concept was referred 
to as Network Centric Warfare (NCW) but is now referred to as net-centric 
capabilities or net-centric operations. The concept of NCW has been defined in 
different ways throughout its history, but all the definitions share similarities. In its 
broadest definition as provided by the Command and Control Research Program 
(CCRP) in its 1999 publication. Network Centric Warfare: Developing and 
Leveraging Information Superiorib/, NCW is defined as: 

An information superiority-enabled concept of operations that 
generates increased combat power by networking sensors, 
decision makers, and shooters to achieve shared awareness, 
increased speed of command, higher tempo of operations, greater 
lethality, increased survivability, and a degree of self¬ 
synchronization. (Garstka & Stein, 1999) 

In other words, the NCW strategy is characterized by the linking of people, 
platforms, weapons systems, sensors, and decision aids into a single networked 
environment (DoD OFT, 2005). The NCW theory is further defined in terms of its 
four tenets that describe the enhanced power of a networked force: (1) a robustly 
networked force improves information sharing, (2) information sharing enhances 
the quality of information and shared situational awareness, (3) shared situational 
awareness enables collaboration and self-synchronization, and (4) these, in turn, 
dramatically increase mission effectiveness (DoD, 2001). 

Network Centric Warfare (NCW) was the cornerstone of the DoD’s 
transformation process, and the Department placed great emphasis on the 
capabilities produced by this strategy. In fact, much had been accomplished in 
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the era of NCW including the development of newer technologies and systems, 
the creation of new military occupational specialties (MOS) and departments (i.e., 
the Office of Force Transformation, now defunct). The biggest accomplishment 
has been the impact on operations. According to the 2006 Quadrennial Defense 
Review (QDR), operational experiences in both Iraq and Afghanistan have 
demonstrated the value of network centric warfare (DoD, 2006). In both theaters 
of war, critical relationships were enabled via network-centric capabilities that 
allowed for faster operational decision making. By harnessing the power of 
information through connectivity, operating forces were able to gain greater 
situational awareness and show the value of NCW. General Stanley A. 
McChrystal (2010), former Commander of International Security Assistance 
Force (ISAF) and U.S. Forces Afghanistan, credited network centric theory in his 
review of the progress experienced in Iraq and Afghanistan (Younker, 2010). 
Furthermore, the special operations mission that targeted Osama bin Laden 
exemplified aspects of the NCW strategy in its speed and agility, collaboration 
with higher headquarters, decentralization of the small unit, and decisive speed 
in accomplishing the mission (Elkus, 2011). These recent combat experiences 
highlight the importance of IT systems with its ability to fuse data from broad 
ranges of sources both within and outside of the DoD. 

Although there has been some success in using the net-centric 
strategy, it has also had its problems. According to the Defense Science Board 
(DSB) (2009) in reference to a 2006 DSB study regarding information 
management for net-centric operations: 

Information management in Iraq and Afghanistan was a principal 
concern among warfighters. Significant ad hoc activity was taking 
place, especially at the tactical level, to gain desired capability. To 
counter the interoperability problem, many approaches were used 
to move information from one stove-pipe to another...much of the 
military capability used to support the conflicts was paid for with 
supplemental funding—programs that were not part of the 
Department’s planned capability. This circumstance reflects the fact 
that the need for such programs could not be predicted during 
previous core program and budget planning, and the system was 
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not sufficiently agile to react once the need was apparent. (DSB, 

2009) 

These problems experienced in combat were due in large part to not having the 
right systems in place to better manage information but was also due to the 
ineffective acquisition process that was in use to facilitate warfighter needs and 
requirements. Despite these problems, much has been written on the 
advantages and benefits resulting from the net-centric strategy and the promise it 
holds for the future. However, the implementation of the net-centric strategy has 
not come without challenges, which have served to stymie full integration of the 
strategy. 

Some of these challenges to implementing the net-centric strategy 
can be linked to the ineffectiveness of the IT acquisition system. The DoD’s 
overall strategy for implementing NCW theory was based on three principles. The 
first principle involved setting priorities to enable, develop, and implement net- 
centric concepts and capabilities. These priorities encompass networking a 
critical mass of the Joint Force, an increased emphasis on research in 
developing situational awareness and approaches to achieving synchronization, 
and research to improve the DoD’s ability to accurately represent net-centric 
related concepts in models and simulations (DoD OFT, 2005). The second 
principle consisted of establishing specific goals and measuring progress. The 
DoD recognized the importance of establishing measurable goals to assess 
progress and validate the utility of the net-centric strategy. The third principle 
consisted of overcoming any impediments to progress. It is this principle that has 
not been effectively adhered to because an impediment to progress is in the 
failure to acquire IT systems in a timely manner in order to meet mission 
requirements. Thus, the net-centric strategy has not been fully realized in the 
years since its inception due to a number of issues including acquisition related 
problems. As described in the Defense Science Board’s 2009 report to 
Congress, failures within IT acquisition have roots in the failure to fully realize the 
vision of the DoD’s transformation strategy: 
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Certainly, barriers that preclude transformation of the U.S. national 
security apparatus to meet the challenges of a new strategic era 
are of particular concern. Nearly a decade ago the Department 
established a vision for the architecture and structure for 
information system management—a vision that is still evolving. 
However, it is well known that acquisition has not been well 
managed for these systems within this “enterprise level” 
construct, and the result has not served today’s leaders and 
soldiers well. In fact it hinders the warfighters’ ability to use 
information technology to its fullest potential for situation 
awareness, collaboration, and rapid decision-making. The resulting 
operational impact is profound. (DSB, 2009) 

With warfare now being waged in the Information Age, the DoD 
may be at risk of losing its competitive advantage of information superiority if IT 
acquisitions do not enable the full implementation of the net-centric strategy. 
Failure to implement this strategy may reduce the DoD advantages in conducting 
twenty-first century warfare and place the military at a disadvantage, especially in 
cyberspace. The 2010 Quadrennial Defense Review (QDR) speaks specifically 
about how operating effectively in cyberspace for the security environment 
demands improved capabilities to counter cyber threats. Furthermore, modern 
armed forces simply cannot conduct effective high-tempo operations without 
resilient, reliable information and communication networks and assured access to 
cyberspace (Daggett, 2010). Therefore, it is imperative that the DoD work to 
resolve all impediments to acquiring newer technologies in order to maintain 
information superiority in warfare. 

The war on terrorism over the past decade has shown us that 

national security threats can come from many diverse areas including domestic 

and international terrorists groups, state/non-state actors, computer hackers, and 

others. It is clear that terrorist groups and other non-state actors have come to 

characterize warfare and conflicts in the twenty-first century, and their continued 

growth and power will remain a key issue of the information environment. Due to 

globalization, there has been a transformation of the process of technological 

innovation due to the lowering of entry barriers for a wider range of actors and 

potential adversaries to develop and acquire advanced technologies (Daggett, 
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2010). Adversaries around the world are acquiring these new technologies and 
are potentially gaining an advantage as we fail to acquire newer technologies in 
an effective and timely manner. The speed with which potential adversaries can 
adapt, procure, and employ newer capabilities against the United States has 
been impressive. Moreover, our adversaries are better able to manipulate the 
information environment by employing a challenging mix of tactics and 
technologies, which will increasingly be an important part of the future spectrum 
of conflict (Daggett, 2010). 

According to the DoD Chief Information Officer, Teresa Takai, “U.S. 
networks are under constant attack from cyber security threats launched from the 
Internet or from malicious software embedded in e-mail attachments, removable 
media, or even embedded in the hardware the Department procures” (Improving 
Management and Acquisition of Information Technology Systems in the 

Department of Defense, 2011). Takai goes on to state that, “every single device 
connected to the network is susceptible to a cyber attack” (Improving 
Management and Acquisition of Information Technology Systems in the 

Department of Defense, 2011). This is especially concerning because the DoD is 
constantly striving to integrate and network more and more systems, so we are 
even more susceptible. 

Leveraging information technology to deliver mission-critical 
information capabilities to warfighters is one of the primary goals of IT. There was 
a time when the DoD sought to balance the need to know with the need to share 
information; however, today the warfighter expects to have and needs to have 
the latest information in order to accomplish the mission (Improving Management 
and Acquisition of Information Technology Systems in the Department of 
Defense, 2011). The need to know the latest information, coupled with the 
increasing use of the latest technologies from smart phones to mobile computers, 
has made information-sharing an expectation. Thus, this expectation requires 
new capabilities, especially in tactical environments. IT offers inestimable 
capability and has been leveraged extensively in order to build national security 
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systems, business systems, and weapons systems. As the Department 
continues its transformation to meet the challenges of the twenty-first century, it 
will continue to rely on the increased functionality that IT provides, so acquisition 
processes have to be made more effective. Thus, the continued implementation 
of net-centric capabilities via effective IT acquisition is of the utmost importance 
in continuing the transformation process within the DoD. 

3. Acquisition of Information Technoiogy within the DoD 

a. Information Technology Expenditures within the DoD 

The DoD is an immensely large and complex organization that 
consists of the Office of the Secretary of Defense (OSD), the Joint Chiefs of Staff 
(JCS), the military departments, numerous defense agencies and field activities, 
and various unified combatant commands. With this much manpower, the DoD is 
the largest organization in the world, with operations that span a broad range of 
agencies, activities, and commands. Furthermore, the DoD is the nation’s largest 
employer with over 1.4 million military personnel on active duty, more than 
750,000 civilian personnel, and over one million serving in the National Guard 
and Reserve (DoD, 2010). Additionally, there are nearly 6 million military family 
members and retired personnel who receive benefits. 

According to a 2010 Government Accountability Office (GAO) 
report regarding DoD business transformation, “in fiscal year 2009, DoD reported 
that its operations consisted of $1.8 trillion in assets, $2.2 trillion in liabilities, 
approximately 3.2 million military and civilian personnel and disbursements of 
over $947 billion” (GAO, 2010). Of course, this 2009 budget may not rival future 
defense spending given the current fiscal situation within the federal government, 
but these figures point out the large sums of money spent within the DoD and a 
significant portion of these expenditures are used for acquiring information 
technology. 

Much like the commercial business world, the DoD runs on 
information and continues to require more and more of it via IT systems in order 
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to achieve an information advantage. In an effort to support the diverse IT 
requirements of the DoD’s huge population, the DoD employs approximately 
15,000 unclassified networks, more than seven million computers and associated 
IT devices, and a 170,000-person information management and information 
technology workforce (DoD, 2010). With these large numbers of systems, it is 
clear that information technology is a crucial factor in every aspect of the DoD’s 
activities. From routine e-mail to the weapons control systems in the most 
sophisticated ships in world, the DoD depends on the smooth functioning of a 
myriad of IT systems and the acquisition process that provides them. 

As the Information Age advances, we find that IT systems have 
expanded both in complexity and in pervasiveness and as a result, they 
represent one of the largest investments for the DoD today. For example, the 
GAO, which is the investigative arm of the federal government, reported that in 
fiscal year 2011 the DoD allotted approximately $36.6 billion for its IT 
investments and $5.6 billion of this amount was allotted for major automated 
information system (MAIS) programs that the DoD required in order to sustain 
key operations (GAO, 2013). The millions of people who are employed by the 
DoD operating worldwide maintain an inventory of systems and services that 
accounts for these expenses and it is an order of magnitude larger than any IT 
expense in the world. The DoD’s IT acquisition expenditures in comparison to 
other DoD expenditures are relatively small but they constitute an extremely 
important business function within the Department. However, there are growing 
concerns involving all DoD expenditures due to government fiscal issues and 
projected decreases in the DoD budget. As a result, IT acquisition issues, 
especially the IT funding process issue that will be discussed in Chapter II, will 
only be exacerbated in the event of budget cuts. 
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b. Acquisition Poiicy within the DoD 

The purpose of the Defense acquisition system in the DoD is 
explained in this excerpt from DoD Directive (DoDD) 5000.01, and understanding 
this sets the foundation for this study: 

The Defense Acquisition System exists to manage the nation’s 
investments in technologies, programs, and product support 
necessary to achieve the National Security Strategy and support 
the United States Armed Forces. The investment strategy of the 
Department of Defense shall be postured to support not only 
today’s force, but also the next force, and future forces beyond that. 

The primary objective of Defense acquisition is to acquire quality 
products that satisfy user needs with measurable improvements to 
mission capability and operational support, in a timely manner, and 
at a fair and reasonable price. (USD[AT&L], 2007) 

The emphasis of this thesis relates to the objective of acquiring IT “in a timely 
manner”; however, the other objectives of quality products and reasonable 
pricing are equally important in a DoD IT acquisition program. A DoD acquisition 
program is generally defined as a directed, funded effort that provides a new, 
improved, or continuing materiel, a weapon or information system, or a service 
capability in response to an approved need or requirement shortfall (USD[AT&L], 
2007). The Defense acquisition system is a management process used to 
provide effective, affordable, and timely systems (USD[AT&L], 2007). 
Additionally, the acquisition process includes designing, engineering, testing and 
evaluating, production, and operations and support of Defense systems (Brown, 
2010). As used herein, the term “IT acquisition” will apply only to information 
technology systems, processes, procedures, services, and end products that do 
not include weapons systems with embedded IT (e.g., IT that provides the control 
systems of aircraft weapons platforms). For this study, IT acquisition will only 
refer to military-unique applications that support intelligence, logistics, command 
and control, and services that provide basic desktop computing and other 
infrastructure support. Also, this study refers to the acquisition of major 
automated information systems (MAIS) that are associated with the performance 
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of routine administrative and business tasks such as payroll, accounting 
functions, and logistics (Brown, 2010). 

For many years, information technology acquisition has been a 
subset of the larger acquisition policy within the DoD. In fact, DoD’s acquisition 
policies and regulations were primarily designed to meet the needs of large 
weapons programs (NRG, 2010). In the past, it has taken significant tailoring to 
accommodate IT programs due to acquisition instructions focusing almost 
exclusively on weapons system acquisition and on Major Defense Acquisition 
Programs (MDAPs) such as ship and aircraft procurement. The strategic 
guidance used to shape the entire Defense acquisition program can be found in 
the department’s acquisition policies and regulations. 

The two major DoD regulatory documents that guide the 
management of Defense acquisition are captured in two documents: DoD 
Directive (DoDD) 5000.1, “The Defense Acquisition System,” and DoD Instruction 
(DoDI) 5000.2, “Operation of the Defense Acquisition System.” DoDD 5000.01 
provides a basic set of definitions and three overarching policies that govern the 
Defense acquisition system: flexibility, responsiveness, and innovation; while 
DoDI 5000.02 intends to establish a simplified and flexible management 
framework for translating mission needs and technological opportunities into 
stable, affordable, and well-managed acquisition programs (NRG, 2010). Also, 
DoDI 5000.02 intends to establish a general approach for managing all defense 
acquisition programs (NRG, 2010). Although DoDI 5000.02 has good intentions, 
the instruction does not effectively support the acquisition of IT systems. In fact, 
both DoDD 5000.01 and DoDI 5000.02 focus almost exclusively on weapons 
system acquisition and on MDAPs; however, DoDI 5000.02 contains one short 
section on IT acquisition found in Enclosure 5, which consists of only 3 pages in 
the 80-page document. This fact leads into an acquisition problem area regarding 
the inattention to IT specific acquisition, a fact that will be discussed later. 

The oversight of the acquisition system is an essential and 

important part of the acquisition process and this oversight is grouped into three 
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major decision-support systems: the Joint Capabilities Integration and 
Development System (JCIDS); the Defense Acquisition System; and the 
Planning, Programming, Budgeting and Execution (PPBE) process. These 
decision-support systems will be discussed in Chapter III but a general 
description of each one is as follows: 

The Joint Capabilities Integration and Development System is the 
system that identifies and documents warfighter needs or 
requirements (i.e., mission deficiencies or technological 
opportunities); the Defense Acquisition System, establishes a 
management framework for translating the needs of the warfighter 
and technological opportunities into reliable, affordable, and 
sustainable systems; and the Planning, Programming, Budgeting 
and Execution Process prescribes the process for making decisions 
on funding for every element of the Department, including 
acquisition programs. (Brown, 2010) 

Additionally, the oversight process employs a layered approach to oversight, 
which is based on the level of investment or how much funding is provided to a 
program (DSB, 2009). All programs are generated at the component level along 
with the program requirements. Many programs are reviewed at the origin by 
designated component milestone decision authorities (MDAs). The most 
significant investments, programs categorized as major automated information 
systems (MAIS), receive additional review within the Office of the Secretary of 
Defense (OSD) (DSB, 2009). Also, there is congressional oversight, which will be 
discussed further in the next section. 

For purposes of program management, all Defense acquisition 
programs are broken down into different acquisition categories (ACATs). Each 
ACAT level is based on the type of acquisition desired, its dollar value, and the 
level of milestone decision authority (MDA) it rates. MDA is the action of 
approving or disapproving program progress or advancement into follow-on 
phases. There is a chain of authority along with organizational players who are 
intimately involved at each ACAT level. ACAT designations for automated 
information systems (AIS) involve systems of computer hardware, software, data, 

or telecommunications that perform functions such as collecting, processing, 
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storing, transmitting, and displaying information; excluded are computer 
resources that are a part of a weapons systems (Brown, 2010). Figure 3 displays 
ACATs for IT. 


Category 

Criteria for Designation 

Decision Authority 

ACATIA 

• Major Automated Information 

System (MAIS) 

- Designated by the MDA 

as an MAIS, or 

- Estimated to exceed: 

■ Program costs in any 
single FY (all appro¬ 
priations), $32M, or 

■ Total program costs (all 
appropriations) from 
beginning of Concept 
Refinement through 
deployment at all sites, 
$126M, or 

• Total life cycle costs (all 
appropriations), $378M 

• MDA designation as special 

interest 

• ACATIAM: 

- USD(AT&L) or designee 

- Reviewed by the 

Information Technology 
Acquisition Board 

• ACAT lAC: Component head, 

or Component Acquisition 
Executive (CAE) (cannot be 
further delegated) 

- Reviewed by component 

HQ 

ACAT II 

• Does not apply to MAIS 
programs 

• N/A 

ACAT III 

• Does not meet ACAT lA (MAIS) 
criteria 

• Designated by the CAE at the 

lowest appropriate level 

• Reviewed in accordance with 

component policy 


Figure 3. Acquisition Categories for IT (amounts in FY2000 constant dollars) 

(From Brown, 2010) 


Major automated information system (MAIS) acquisition programs 
are designated ACAT lA programs. There are two subcategories of ACAT lA 
programs, which are as follows: 

• ACAT lAM, for which the milestone decision authority is the 
USD(AT&L) or, if delegated, the Assistant Secretary of Defense for 
Networks and Information Integration. The “M” refers to major 
automated information systems reviewed by the Information 
Technology Acquisition Board. 
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• ACAT lAC, for which the milestone decision authority is delegated 
to the component. The “C” refers to component. After the 
appropriate headquarters review, the Component Acquisition 
Executive (CAE) makes the final milestone decision. 

• The ACAT II designation does not apply to automated information 
systems. ACAT III automated information systems are those that do 
not meet the criteria for ACAT lA. (Brown, 2010). 

c. Defense Acquisition Management: Key Personnei and 
Oversight 

There is a chain of authority and many organizational players who 
are involved at each ACAT level and throughout the acquisition process. 
Currently, acquisition authority and expertise within the DoD is spread across 
different organizations, which is problematic; and a matter that will be discussed 
in detail later. According to DoD Directive 5134.01, the primary management 
agency of the DoD Acquisition System is the Under Secretary of Defense for 
Acquisition, Technology and Logistics (USD[AT&L]) who is currently Mr. Frank 
Kendall (DoD, 2008). The USD(AT&L) is the principal staff assistant and advisor 
to the Secretary of Defense and Deputy Secretary Defense for all matters 
concerning acquisition, technology, and logistics (“Office of the Under Secretary 
of Defense for Acquisition, Technology and Logistics,” n.d.. Welcome To AT&L 
section, para. 1). The primary responsibilities of the USD(AT&L) include 
supervising DoD acquisition; establishing policies for acquisition (including 
procurement of goods and services, research and development, developmental 
testing, and contract administration) for all elements of the Department; and 
establishing policies for the DoD for maintenance of the Defense industrial base 
of the United States (“Office of the Under Secretary of Defense for Acquisition, 
Technology and Logistics,” n.d.. Welcome To AT&L section, para. 1). The 
USD(AT&L) also serves as the Defense Acquisition Executive (DAE) and 
Milestone Decision Authority (MDA) for ACAT lA programs as identified in Figure 
3 under Decision Authority. 
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Two other OSD-level organizations or offices are integral to the IT 
acquisition process: the DoD Chief Information Officer (formerly the Assistant 
Secretary of Defense [Networks and Information Integration/DoD CIO]) and the 
Office of the Deputy Chief Management Officer (ODCMO) for the DoD. Due to 
fiscal concerns, the Assistant Secretary of Defense for Networks and Information 
Integration (ASD[NII]), who was the principal OSD staff assistant for the 
development, oversight, and integration of DoD policies and programs relating to 
the strategy of information superiority, was dissolved into other DoD departments 
(“DoD News Briefing with Secretary Gates from the Pentagon,” 2010). The 
ASD(NII) was dual-hatted and served as the Chief Information Officer of the 
Department. The DoD CIO is the Principal Staff Assistant (PSA) and advisor to 
the Secretary of Defense (SECDEF) and Deputy Secretary of Defense 
(DEPSECDEF) and is tasked with improving the combat power of the 
Department by ensuring that the Department treats information as a strategic 
asset and that innovative information capabilities are available throughout all 
areas of DoD supporting warfighting, business, and intelligence missions (“DoD 
CIO Mission,” n.d.). The DCMO is responsible for synchronizing, integrating, and 
coordinating the business operations of the Department and ensuring optimal 
alignment in support of the warfighting mission (“About DCMO,” n.d.. About 
DCMO section, para. 1). These two DoD agencies and the USD(AT&L) comprise 
the power structure of the DoD acquisition system; however, there are many 
other entities that play important roles and also hold considerable power. 

Other important entities in the acquisition process involve the 
Component Acquisition Executive (CAE), the Program Executive Officer (PEO), 
and the Program Manager. The CAE is the senior official in each DoD 
component who is responsible for acquisition matters (Brown, 2010). Normally, 
the CAE serves in a primary duty capacity as either the secretary of the military 
department or as the head of the Defense agency. In the case of military 
departments, the secretaries may delegate this responsibility to the assistant 
secretary level, which is then referred to as the Service Acquisition Executives 
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(SAE) (Brown, 2010). The PEO is normally a general officer but can also be a 
Senior Executive Service (SES), which is a civilian equivalent. The PEO is 
responsible for first-line supervision of a group of like programs and each 
managed by separate Program Managers (PM) (Brown, 2010). Last, and 
certainly not least, is the Program Manager (PM). 

The PM is arguably the most significant person in the acquisition 
process, not necessarily for possessing a lot of power but due to his or her 
proximity to the project. The PM is the designated individual with responsibility for 
and authority to accomplish program objectives. These objectives include 
development, production, and sustainment to meet the user’s operational needs 
(DoDD 5000.01). Ultimately, the PM is accountable for what is considered the 
holy trinity of any program or project: cost, schedule, and performance. If the PM 
is not knowledgeable, experienced, and consistent in terms of his or her 
availability throughout a program, the IT acquisition process is more likely to 
experience problems. Unfortunately, issues surrounding the IT acquisition 
workforce, to include the PM, have caused problems, which will be discussed in 
more detail later. 

There are many other DoD agencies, organizations, and 
stakeholders along with several other offices within the Executive Branch that are 
involved in the acquisition process. In no particular order, these entities include 
the following: 

• IT Acquisition Advisory Council 

• Overarching Integrated Product Teams (OIPTs) which are 
specialized review teams 

• Investment Review Board (IRB) 

• Chief Information Officers (CIO) for the military departments 

• Program Analysis and Evaluation (PA&E) 

• Director of Defense Research and Engineering (DDR&E) 

• Operational Test and Evaluation (OT&E) 
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• Office of Management and Budget (0MB) 

• Office of Federal Procurement Policy (OFPP) 

• Federal Acquisition Regulations Council 

• Comptroller 

• Operational users and other stakeholders (Brown, 2010) 

All these different entities, plus the three main OSD-level organizations and/or 
personnel, comprise the management and acquisition team or acquisition 
workforce for the entire DoD IT acquisition system. The three main entities 
provide a line of authority in the acquisition process that runs from the 
USD(AT&L), through the CAE and PEO to the individual PMs of the ACAT lA 
programs (Brown, 2010). 

With all the different agencies and organizations involved in the 
acquisition process, it can be very difficult to get anything done as planned or as 
scheduled. But, there unto lies the problem because IT acquisition does not 
always get done according to plan or schedule and acquisition workforce issues 
are just one of the problems. Despite the DoD’s success in leveraging IT across 
the defense enterprise, the acquisition of IT systems continues to be burdened 
with problems that result in a failure to meet the primary objective of Defense 
acquisition which again is “to acquire quality products that satisfy user needs with 
measurable improvements to mission capability and operational support, in a 
timely manner, and at a fair and reasonable price” (USD[AT&L], 2007). The next 
chapter begins the discussion of the crux of this study, which will explore the 
problems that have plagued the Defense acquisition system over the past 
decade. 


25 




G. ORGANIZATION OF THESIS 

The thesis is organized within five chapters. Chapter I is an introduction to 
the problems within the IT acquisition system and details the framework for this 
study. Also, Chapter I discusses the importance of IT and IT acquisition within 
the DoD in order to achieve national defense objectives. Chapter II consists of a 
thorough literature review of the acquisition research conducted since 2009: 
government reports, academic papers, and proposed strategies for reforming the 
IT acquisition system. Chapter III discusses background information on IT 
acquisition reform efforts and an overview of the current DoD acquisition 
systems. Chapter IV presents an analysis of both benefits and shortfalls of the 
current IT acquisition process and looks at other potential solutions, offering a 
recommended approach to IT acquisition. Finally, Chapter V closes the study 
with persisting issues in connection with the current IT acquisition system, a 
summary, findings and recommendations, and conclusion. 
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II. LITERATURE REVIEW 


This chapter consists of a thorough review of the information technology 
(IT) acquisition literature that has been written since 2009. This literature will 
include government reports, articles, academic papers, and other documents. 
The goal of this chapter is to provide the reader with an understanding of all the 
major problems surrounding IT acquisition within the DoD. These IT acquisition 
problems consist of a misalignment of the Defense Acquisition System to IT 
development, lengthy developmental timelines, testing and evaluation issues, 
legislative impediment and oversight, requirements and funding issues, and 
acquisition workforce and management related issues. Ultimately, this chapter 
will provide an extensive look at these problems to provide a context in order to 
set the reader up to begin a study of possible solutions which will be discussed in 
Chapters III through V. 

A. PROBLEMS WITHIN THE DOD IT ACQUISITION SYSTEM 

Information technology has been used in virtually all types of 
organizations, especially government and business organizations. To facilitate 
dealing with the complex tasks and business operations of the twenty-first 
century, commercial businesses and government agencies utilize networked IT 
systems such as Enterprise Resource Planning (ERP) and Supply Chain 
Management integration in order to enhance their operations. However, 
commercial businesses (e.g., FedEx and Wal-Mart) have successfully undergone 
a fundamental transformation of their business practices via information 
technology while government agencies have been less successful doing so and 
are still in the process of transformation (Gansler & Lucyshyn, 2012). 

Government agencies such as the DoD have not been able to leverage 
the full potential that IT systems offer in regard to productivity. In fact, the DoD 
continues to lag far behind the capabilities demonstrated within the private sector 
(Gansler & Lucyshyn, 2012). The DoD’s “lagging behind” is directly linked to the 
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issues found within the IT acquisition system today. These issues present a 
significant problem because as the IT acquisition processing times increase, so 
does costs; but more importantly, benefits are slower to be achieved. With that, 
there has been growing concern among the DoD and Congress that our nation’s 
military advantage may be eroding due to the problems and inefficiencies within 
the IT acquisition system. It is important now to take an extensive look at what 
constitutes the problem or problems with the DoD IT acquisition system. 

There have been no shortages of studies, reports, and reviews that have 
identified many of the problems that have plagued the DoD IT acquisition system. 
Thus, there is a recognized and compelling need to address these problems, 
bottlenecks, and discontinuities within the system. This review of the IT 
acquisition problems will analyze the following six documents, which include 
government reports, hearings, articles, and academic papers that have described 
the IT acquisition problems over the past several years: 

• Defense Science Board Task Force on DoD Policies and 
Procedures for Acquisition of IT (DSB, 2009) 

• Rapid IT Acquisition: A New Model for Acquiring Government 
Information Technology (Gilligan, Heitkamp, & McCoy, 2009) 

• Achieving Effective Acquisition of Information Technology in the 
Department of Defense (NRG, 2010) 

• House Armed Services Committee Panel on Defense Acquisition 
Reform Findings and Recommendations (HASC, 2010) 

• A New Approach for Delivering Information Technology Capabilities 
in the Department of Defense (DoD, 2010) 

• IT Acquisition: Expediting the Process to Deliver Business 
Capabilities to the DoD Enterprise (Gansler & Lucyshyn, 2012) 

The authors of these various publications place similar yet different 
emphasis on what they construe as the problem or problems within the IT 
acquisition system but all have ended with the same conclusion that these 
problems need to be resolved in order to make the IT acquisition system more 
timely and effective. Overall, the problems identified all affect the three things 
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that are most important to any acquisition program: cost, schedule, and 
performance. Every information technology acquisition program’s goals are to get 
the project done within an assigned budget and on time while providing end 
users with the required capabilities. Of these three program goals, which are all 
important, this study will focus on the scheduling goal because scheduling issues 
are directly related to DoD agencies and the warfighters getting needed 
capabilities in a timely manner in order to accomplish their specific missions. 
Also, scheduling issues have a direct impact on cost, which in this current fiscal 
environment of reduced Defense budgets is of the utmost importance. 
Performance, however, is a separate issue all together and will not be discussed 
in great detail but it will be discussed as it relates to schedule. 

Of the six documents reviewed, the 2009 Defense Science Board’s 
Department of Defense Policies and Procedures for the Acquisition of 
Information Technology is a seminal work dealing with problems in DoD IT 
acquisition. In fact, the problems in the IT acquisition system were not made a 
priority until this report was published. All of the other documents reviewed here 
expand from the issues made relevant by the DSB report. IT acquisition 
problems, as described in the literature, fall into six categories or problem areas 
that are as follows: 

• The Defense Acquisition System Ill-suited for IT Acquisition 

• Issues Extending From Lengthy Acquisition Timelines 

• Testing and Evaluation Issues 

• Legislative Impediment and Oversight Issues 

• Requirements and Funding Issues 

• Acquisition Workforce and Management Issues 
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B. THE TRADITIONAL DEFENSE ACQUISITION SYSTEM ILL-SUITED 

FOR IT ACQUISITION 

As stated by the authors of Rapid IT Acquisition: A New Model for 
Acquiring Government Information Technology, “Information Technology tends to 
have different characteristics from many other items the government acquires, 
which means that the typical government acquisition processes are not optimum 
for IT procurements (Gilligan, Heitkamp, & McCoy, 2009). The authors go on to 
state that “lengthy and deliberate processes used to acquire weapons systems in 
DoD, Coast Guard ships for the Department of Homeland Security, or a nuclear 
fusion test laboratory for the Department of Energy would not be good models for 
acquiring tax payment processing systems or law enforcement fugitive 
databases” (Gilligan et al., 2009). Information technology acquisition differs from 
other types of procurements in a few ways. As outlined by Gilligan, Heitkamp, 
and McCoy (2009), the underlying differences in IT that distinguishes it from 
other types of procurements, products, and services are as follows: 

• The technology for information systems exhibits continuous and 
very rapid evolution. 

• There are an increasing number of commercial off-the-shelf 
(COTS) components available. 

• Users’ requirements for an information system evolve as users gain 
experience with early capabilities. 

• Most IT systems or services are components of a larger “system of 
systems.” (Gilligan et al., 2009) 

The traditional DoD’s Acquisition System is setup to support larger 
procurements or platforms such as weapons systems, ships, and aircraft. Due to 
procurement laws, regulations, and policies, all DoD acquisitions had to follow 
the framework of the Defense Acquisition System. As previously mentioned, the 
two most important documents governing acquisition are DoD Directive 5000.01 
and DoD Instruction 5000.02 and both are focused more on weapons system 
acquisition or Major Defense Acquisition Programs (MDAPs) than on information 
technology. The House Armed Services Committee (HASC) in 2010 stated: 
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The system remains structured primarily for the acquisition of 
weapons systems at a time when [IT] services represent a much 
larger share of the Department’s acquisitions. As a result, the 
Department’s formal acquisition policy has limited application to the 
majority of the Department’s acquisitions...Furthermore, while the 
Department is currently working to modernize in the “Information 
Age,” the acquisition system is particularly poorly designed for the 
acquisition of information technology. (HASC, 2010) 

The traditional acquisition system lacks the flexibility, agility, and 
responsiveness that are necessary to support the DoD and the warfighter. Thus, 
one of the primary acquisition problems is the DoD’s “one-size-fits-aN” acquisition 
system that has failed to produce the required IT systems on schedule and within 
budget. According to Gansler and Lucyshyn (2012) in IT Acquisition: Expediting 
the Process to Deliver Business Capabilities to the DoD Enterprise, “nearly half 
of all major federal IT projects undertaken have experienced delays or changes 
to requirements that have led to cost and schedule overruns and program 
restructuring” (Gansler & Lucyshyn 2012). In 2010, the House Armed Services 
Committee (HASC) Panel on Defense Acquisition Reform reported that the 
delivery of Defense IT systems required 48 to 60 months to be completed 
(HASC, 2010). This long period of time is significant based on the fact that the 
commercial acquisition process has produced newer information technologies 
much quicker, typically within a fraction of the time it takes the DoD. 

Some of the IT acquisition time taken in the traditional acquisition process 
can be accounted for in such actions as risk assessments and risk reduction. As 
stated by Timothy Harp (2009), Deputy Assistant Secretary of Defense for 
Command, Control, and Communications, Intelligence, Surveillance, 
Reconnaissance and Information Technology Acquisition, in his 2009 testimony 
to the HASC on Acquisition Reform, “[the] weapons system acquisition process is 
optimized to manage production risk and doesn’t really fit information technology 
acquisition that does not lead to significant production” (Challenges to Effective 
Acquisition and Management of Information Technology Systems, 2009). Since 
the threshold of risk management for the traditional defense acquisition system 
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requires a higher risk than for the typical “mature technology” or commercial off- 
the-shelf (COTS) product used to produce Defense business systems, the 
traditional Defense acquisition process does more harm than good when 
acquisitioning Defense business systems (Gansler & Lucyshyn, 2012). Moreover, 
the design of the traditional acquisition system helps to reduce the risk 
associated with multibillion-dollar investments and complex weapons programs 
by using repetitive and detailed reporting requirements to provide visibility so that 
problems can be identified early in the acquisition process. Long durations are 
understandable for weapons system acquisition processes due to the extensive 
and detailed process that includes Joint Capabilities Integration and 
Development System (JCIDS) initiation through full development (HASC, 2010). 
However, Defense business systems can be developed with less inherent risk so 
extensive and repetitive documentation used in weapons systems acquisition are 
problematic and result in more time spent in the acquisition process (Gansler & 
Lucyshyn 2012). 

C. ISSUES EXTENDING FROM LENGTHY ACQUISITION TIMELINES 

Commercial IT acquisition processes utilize industry standards and best 
practices and essentially exercise a more efficient process to develop newer 
technologies in a timely manner. In fact, the commercial sector is able to deliver 
IT capabilities and incrementally improve on those initial deliveries in 12 to 
18 months (HASC, 2010). With Defense IT systems typically taking 48 to 60 
months to be delivered, DoD system are not as timely despite two major 
influences that encourage more timeliness. The first influence is the pace of 
technology change, which puts pressure on acquisition timelines in order to 
ensure relevancy once the system is delivered (DSB, 2009). Given the nature of 
the Information Age, IT acquisition programs are greatly affected by the rapid 
pace of change in technologies. As mentioned previously, Moore’s Law predicts 
that hardware capability per unit expenditure doubles roughly every 18 months. 
In a commercial market environment dominated by Moore’s Law and a high rate 

of technological change, hardware obsolescence and supportability has become 
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a significant issue that has affected DoD IT acquisition programs. Software, on 
the other hand, is driven by an even-faster pace of technology change due to the 
Internet environment and end-user expectations (Gansler & Lucyshyn, 2012). 
Since DoD IT acquisition programs progress at a much slower rate, the DoD is 
unable to keep pace with the rapid rate of IT innovation in the commercial sector, 
and fails to fully capitalize on IT-based opportunities (NRG, 2010). 

The second major influence on IT acquisition timescales are military 
missions and operational tempo because military operations are requiring 
increasingly more rapid-response times (DSB, 2009). Moreover, decision cycles 
in conventional warfare have shortened from days to hours and in some cases 
even seconds. As reported by the DSB in 2009, “the overall portfolio of DoD IT 
programs has experienced a 21-month delay in delivering initial operational 
capability to the warfighter, and 12 percent are more than four years late” (DSB, 
2009). Worse yet, once the delayed product is received, the end user often finds 
that the requirements, technology, and standards have changed or the 
technology is already two or three generations behind (Gansler & Lucyshyn, 
2012). 

The DoD has relied on an acquisition process that involved many non- 
integrated parts and error-prone processes that were redundant and did not 
provide the visibility necessary to make sound IT acquisition management 
decisions. Of the multiple failings of the Defense acquisition system, one major 
point of failure has occurred at milestone decision points. Milestone decisions will 
be covered in Chapter III, but for now it is only important to know that milestones 
are critical junctures in every acquisition program where a program must gain 
approval from many different functional organizations. For IT, the acquisition 
process tended to stall at milestone decision points because when a system 
reached certain milestones, it could take up to 90 days for a milestone decision 
to be reached (DSB, 2009). These stoppages or delays could easily increase the 
schedule. In addition to the milestone decisions delays, excessive program 
documentation requirements brought on by the traditional acquisition system 
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create additional delays and shifts in scheduling, which further distance the 
existing process from commercial best practices (Gansler & Lucyshyn, 2012). 

D. TESTING AND EVALUATION ISSUES 

Testing and evaluation (T&E), as it relates to IT, is an issue in the 
traditional Defense Acquisition System. Although DoDD 5000.01 states that test 
and evaluation shall be integrated throughout the Defense acquisition process, 
testing is often integrated too late in IT systems acquisition practices 
(USD[AT&L], 2007). Testing is reserved until the end of the developmental cycle 
or administered during the mandated operational testing phase in a realistic 
environment (HASC, 2010). Because testing does not occur throughout the 
development cycle, it can be detrimental to the effective progress of Defense 
business systems acquisition as well as to the integration and interoperability 
objectives sought in most IT projects. Defense business systems are highly 
dependent on user feedback, which can be integrated into the product in the form 
of new features or more intuitive design (Gansler & Lucyshyn, 2012). Failing to 
conduct continuous testing can lead to more developmental time due to intensive 
redesign once issues are discovered following large blocks of untested 
development. Essentially, IT systems that lack continuous testing and evaluation 
cause not only delays but also cost overruns while limiting the potential 
effectiveness of the product (Gansler & Lucyshyn, 2012). Also, unnecessary 
testing can waste time and cause delays. According to Teresa Takai, DoD Chief 
Information Officer (CIO), in her remarks during a 2011 congressional hearing on 
improving the management and acquisition of IT systems in the DoD, “we will 
need to look at our testing and accreditation processes, because that is one of 
the inhibitors that we are aware of today in terms of retesting platforms for every 
upgrade as opposed to recognizing that there are standard platforms and there is 
not the need to test” (Improving Management and Acquisition of Information 
Technology Systems in the Department of Defense, 2011). Takai’s comment is in 
regard to the use of commercial systems that include commercial off-the-shelf 
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(COTS) products that have already been tested and approved but essentially go 
through a retesting process. 

In regard to COTS technologies, they are not only inefficiently tested but 
they are also insufficiently leveraged, excessively tailored, and excessively 
delayed, according to the National Research Council (NRC, 2010). In fact, many 
programs have experienced acquisition lead times that have significantly 
exceeded the lifecycles of the underlying COTS technology by years. This 
happens due to unnecessary testing but also to oversight processes that focus 
too much on potential shortcomings of COTS products and services (NRC, 
2010). As a result, this approach to COTS products inhibits the timely delivery of 
meaningful end-user capabilities. Ultimately, the processes used for the 
acquisition and testing of IT systems can last more than 5 years before a solution 
is delivered to the end users (NRC, 2010). Once again, given the rapid pace of 
change in the IT world, solutions eventually delivered within this time frame are 
often found to be inadequate by end users. 

E. LEGISLATIVE IMPEDIMENT AND OVERSIGHT ISSUES 

The purpose of acquisition oversight in the DoD is for the disciplined 
management of large, expensive, and complex systems (NRC, 2010). 
Throughout the government, oversight processes are exercised by multiple 
oversight constituencies. Oversight for a government IT program can consist of 
acquisition officials, CIOs, DoD officials, and even Congress that authorizes and 
appropriates funds and enact laws governing procurement. Each one of these 
entities can make different demands (e.g., program documentation, reports, and 
briefings) as they exercise their oversight roles. With multiple oversight bodies 
taking part in the program oversight and review process, the acquisition system 
gives undue leverage to entities that often are not true stakeholders (e.g., end 
users) in the process (NRC, 2010). This, imbalance, of course, can have 
negative effects on the program. For instance, too many detailed requirements 
can be included in the program, which may result in the inability to prioritize these 
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requirements effectively. Also, these different requirements could be 
contradictory or extremely difficult to implement. Too much oversight or 
governance can be a barrier in the acquisition of IT. For example, in 2009 the 
Defense Acquisition Performance Assessment Panel stated, “current governance 
structure does not promote program success—actually, programs advance in 
spite of the oversight process rather than because of it” (DSB, 2009). Although 
oversight is intended to be a good thing, some oversight entities are so 
burdensome that they actually slow programs down and even increase the 
probability of failure (Gilligan et al., 2009). 

As mentioned. Congress serves in an oversight role and is very much 
involved in addressing the issues of IT acquisition. In fact, the Defense Science 
Board report stated “Congress has lost confidence in DoD’s execution of IT 
programs, which has resulted in increasing program scrutiny and budget 
actions (generally funding cuts) for programs that are faltering” (DSB, 2009). 
Furthermore, this loss of confidence has resulted in more congressional 
involvement. While acting in their oversight role. Congress has responded to IT 
acquisition issues by adding more restrictive legislative mandates. For example, 
the 2007 National Defense Authorization Act contained unprecedented mandates 
involving the acquisition of IT. These mandates defined the criteria for Major 
Automated Information Systems (MAIS) programs and required annual reports to 
Congress containing the following: development schedule with major milestones; 
implementation schedule including, estimates of milestone dates, initial 
operational capability (IOC) and full operational capability; estimates of 
development and lifecycle costs; and a summary of key performance parameters 
(DSB, 2009). These responses to acquisition problems have not only created 
more oversight and governance, but some of these changes were excessively 
process-centric and even adversarial (NRC, 2010). Even though congressional 
involvement is mandated and actually necessary at times (e.g., authorizing 
funding), over involvement has served to lengthen the IT acquisition process. 
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especially since these mandates create a focus on review documents and other 
process artifacts. These mandates are well-intended changes, but they have 
made the timely delivery of IT capabilities even more difficult. Lastly, excessive 
involvement by Congress could become even more problematic if ever DoD 
begins executing programs well (DSB, 2009). This point is not to undermine 
congressional authority, which is clearly outlined in the Constitution; however, the 
point is simply to highlight the fact that some congressional processes can 
become convoluted, confusing, and inefficient for the DoD acquisition process. 

Another oversight issue involves cost threshold and governance. The DoD 
acquisition framework prescribes elaborate governance or oversight mechanisms 
and cost thresholds that trigger varying levels of review (NRC, 2010). As shown 
in Figure 3, IT programs are assigned acquisition categories that correspond to 
the estimated acquisition cost and are then aligned to the oversight level based 
on these associated cost thresholds (i.e., assignment to a DoD-level agency. 
Service, or program executive officers). The problem lies in the total dollar 
thresholds for designating oversight levels for IT programs because these dollar 
thresholds are significantly lower than those used for weapons systems 
programs (NRC, 2010). The result creates a contrast in which an IT system that 
is an ACAT lA with a development and deployment cost of $126 million over its 
lifecycle has highly centralized oversight at the DoD-level, while a weapons 
system counterpart at the same dollar amount can be decentralized for oversight 
at the program executive officer level (NRC, 2010). Again, this excessive 
oversight creates more layers to traverse, which will assume more transaction 
and decision time. To further exacerbate this issue, as seen in Figure 3, there is 
no provision for major automated information system (MAIS) programs to even 
receive oversight at the Service or agency level (NRC, 2010). 
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F. ISSUES WITH REQUIREMENTS DETERMINATION AND FUNDING 

Requirements determination is the single most important part of the 
acquisition process. Requirements define end user needs and expectations but, 
also, requirements set in motion the intentions and actions of the acquisition 
program. Requirements can be described in two ways: top-level requirements 
(big-R) and detailed requirements (small-r). The difference between the two 
relate to the amount of information that is required. Big-R requirements convey a 
widely recognized purpose, mission, and expected outcome (NRG, 2010). For 
example, a logistics IT system would be assessed on the basis of its ability to 
process a certain number of logistics requests under certain conditions. 
However, small-r requirements involve a set of more detailed requirements 
associated with specific user interfaces and utilities such as the ability to prioritize 
logistics requests based on time or unit (NRG, 2010). Both types of requirements 
are equally important and both can be a source of problems in the acquisition 
process. 

Issues involving requirements have served to lengthen the IT acquisition 
cycle. As described previously, too many detailed requirements levied on IT 
programs by multiple groups can be problematic. But many times, IT program 
requirements are initially written with overly detailed specifications (HASG, 2010). 
At times, these specifications are inconsistent with the pace of technological 
change and need for rapid delivery of capabilities to the end user (HASG, 2010). 
Also, the requirements documents have often been inaccurate descriptions of 
end user needs. The consequence is seen when funding is obtained and the 
acquisition process is initiated because any newly discovered requirement or 
need may not be covered by the budget. The House Armed Services Gommittee 
in 2010 found that the “existing requirements process is ill-suited for the rapidly 
evolving nature of the IT marketplace which requires an iterative dialogue on 
requirements” (HASG, 2010). Moreover, the current process is inflexible and 
prone to over-specification of requirements. As has been the theme throughout 
this study thus far, DoD acquisition, budgeting, and requirements processes are 
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once again designed for large weapons systems acquisition programs, and the 
process of requirements generation is being inappropriately applied to relatively 
low-dollar IT acquisition programs (NRG, 2010). 

Another issue that is closely related to requirements involves the funding 
process for IT solutions, which normally takes years and does not support a 
timely acquisition process. The source of this funding issue is the DoD’s 
Planning, Programming, Budgeting, and Execution (PPBE) system. The entire 
DoD budget is built using the PPBE system. The problem is that this system 
operates on a timeline that does not align well with the fast-paced IT commercial 
marketplace (DoD, 2010). The PPBE offers no flexibility or concessions for IT to 
be able to respond to the rapid changes of the IT environment. For example, 
once a capability shortfall or requirement is acknowledged and generated, it is 
then linked to a funding request to Congress. The request, however, will not be 
provided for immediately but, instead, funding will be provided in a future year. 
An issue then arises when solutions that will rely on IT have to wait for the 
funding process. For instance, the time frame for requesting funding can be 
many times longer than the actual time needed to develop the solution (NRG, 
2010). Essentially, the funding allocation process is not responsive enough to 
address capability shortfalls and requirements as they relate to IT solutions. Not 
only does funding take years to process, but also another complicating factor is 
that IT programs are funded individually. These individual funding processes 
involve three principal types of appropriation: research and development, 
procurement, and operations and maintenance. Also, each of these types of 
appropriations has unique rules and definitions that align funding to a particular 
program. The funding problem then becomes exacerbated when it takes years to 
process and then the funding is not flexible to permit moving it around to support 
new requirements discovered during IT development. 
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G. ACQUISITION WORKFORCE CONCERNS AND MANAGEMENT 

ISSUES 

The Acquisition Workforce includes many career fields such as auditor, 
contracting officer, program management, test and evaluation, and also 
information technology acquisition personnel. The DoD Acquisition Workforce is 
charged with procuring systems and services to meet warfighters’ requirements 
in a timely manner to satisfy national security objectives (NRG, 2010). This 
workforce requires highly trained specialists, especially in the areas of science, 
engineering, testing, business, and program management. These highly trained 
specialists serve as acquisition executives, program managers, and contracting 
officers responsible for the entire acquisition process. In recent years, a number 
of studies have expressed concern about the technical proficiency of the IT 
acquisition workforce and its future status because relatively few in the 
acquisition workforce have specific expertise in information technology (NRG, 
2010 ). 

In the Defense Science Board 2009 report, a review was conducted of 
major IT acquisition programs (MAIS) where cost, schedule, and performance 
were issues. These issues developed from three root causes: 1) senior leaders 
lacked experience and understanding, 2) program executive officers and 
program managers had inadequate experience; and 3) the acquisition process 
was bureaucratic and cumbersome, where many who are not accountable must 
say “yes” before authority to proceed is granted (DSB, 2009). Ghief among these 
problems was the lack of experience. IT acquisition experience, along with 
qualifications, is critical for the DoD, Service leaders, program executive officers, 
and program managers to make the right decisions within an IT acquisition 
program (DSB, 2009). 

Developing, implementing, and managing the acquisition process of IT 
systems require specific and extensive technical knowledge along with 
leadership capabilities. This requirement is needed at the DoD level, the 
Services, and within the larger acquisition community as a whole in order to 
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support acquisition oversight and decision making that occurs at different 
milestones (DSB, 2009). However, this subject matter expertise is often missing 
in government managers, acquisition personnel, and others who are responsible 
for program execution. Not only is IT expertise missing within the DoD, but also 
the competition for talent is increasing, especially within the commercial sector. 
Also, both government and the commercial sector have experienced staffing 
difficulties due to the expected retirement of many in the IT workforce, the small 
number of remaining personnel, and the dismal outlook of incoming personnel to 
fill the ranks (DSB, 2009). The deficiency in requisite knowledge and expertise in 
IT acquisition speaks to a larger problem within the United States regarding 
trained IT professionals. According to the Defense Science Board (2009), the 
long-term supply of U.S. engineering and science students is worrisome and 
arguably a national security concern because over the past 10 years 
undergraduate engineering degrees in the United States have remained flat 
whereas South Korea’s have risen significantly and China’s have grown 
exponentially (DSB, 2009). 

After years of reducing the acquisition workforce in the 1990s, the DoD 
has greatly increased its number of acquisition personnel but they possess 
limited IT acquisition experience (Fryer-Biggs, 2012). According to Frank Kendall 
(2012), USD(AT&L), acquisition personnel need experience and that takes time. 
Kendall also stated: 

My view is that, at the end of the day, the professionalism and the 
capability of the workforce and how it’s supported, more than 
anything else, affects acquisition outcomes...We grow our own 
people. We grow our program managers. We grow our chief 
engineers. We grow our logistic specialists, our private support 
people. We grow our contracting people. And if we have a shortfall 
on that, then we have a very long recovery time to correct it. (Fryer- 
Biggs, 2012) 

The DoD has the means to develop its own trained professionals but even 
that opportunity is limited. The Defense Acquisition University (DAU) is the 
premier source of acquisition training for the DoD. This training emphasizes 
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systems program management and policy compliance among other things. 
However, the acquisition curriculum provided by DAU through the years had not 
adequately addressed the special challenges of IT system acquisition. 
Essentially, DAU did not have a comprehensive program involving IT program 
management and IT testing and evaluation, or training courses designed to 

enhance technical skills (NRG, 2010). Due to this shortfall, DAU was not able to 
prepare program executive officers or program managers to run IT programs 
effectively. 

On-the-job training can take place as well, but this training is not always 
productive. Program mangers that typically manage weapons systems programs 
could assume a PM role for an IT program; however, even if that program 
manager proved to be highly successful at managing weapons systems 
acquisitions, he or she may not be adequately prepared to take on IT systems 
management given the nature of IT technicality and specification (DSB, 2009). 
Ultimately, the DoD does not require program managers to have IT-specific 
knowledge or experience to manage IT programs and this inexperience can be 
detrimental to the program even as they receive on-the-job training. 

Other workforce issues as described by the National Research Council 
are as follows: 

• The DoD rotates personnel too often for any one PM to see an 
acquisition through more than a single milestone 

• The acquisition process rewards the following of acquisition 
processes rather than the delivery of useful and usable capability to 
end users 

• The military culture is a “can do” culture—no program manager 
wants to say that a given task cannot be done 
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• Program size is used as a success metric and is associated, 
overtly, with rank. As a result, program managers are incentivized 
to make programs larger, which contrasts starkly with evidence 
from many studies that smaller programs reduce cost and risk 
(NRG, 2010). 

Of these issues, the DoD’s rotation of acquisition personnel is especially 
problematic along with military personnel who are rotated before an acquisition 
process has matured. Military personnel are extremely important to the 
acquisition process but do not seem to possess as much responsibility as the 
civilians who make-up the majority of the IT acquisition workforce. None of the 
literature reviewed here specifically discusses what the military’s role is or ought 
to be in addressing the IT acquisition problem. Since this problem affects military 
capabilities and operations, it appears that uniformed personnel should have a 
larger and even more significant role in the IT acquisition process. The military 
role as it stands, at least for military-specific systems, normally relates to defining 
end user requirements and some oversight responsibilities (i.e.. Program 
Executive Officer or Program Managers). In regard to end-user requirements, the 
requirements generation portion of acquisitions has already been identified as a 
problem area within the IT acquisition process. Military personnel, as well as 
civilian acquisition personnel, limited tenure in an IT acquisition program can 
create discontinuity and experience gaps, and can hinder program progress. This 
workforce or personnel issue speaks to the overall management issues that have 
plagued the acquisition system. These management and programmatic issues 
begin at the very top level of the DoD with issues of roles and responsibilities. 

In past years, and perhaps even still, DoD agencies have had issues with 

roles and responsibilities regarding the management of the IT acquisition system 

(DSB, 2009). These issues may occur because acquisition authority in the DoD 

is spread across several different organizations, which can result in a lack of 

coordination or synchronization. Although the Under Secretary of Defense for 

Acquisition, Technology, and Logistics USD(AT&L) appears to have the most 
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control over IT acquisition, the Secretary of Defense has many other offices that 
contribute to the decision-making process and acquisition of information 
technology, and these offices serve separate functions and provide different 
services within the DoD. These various DoD offices are depicted in Figure 4 and 
include the Chief Information Officer (CIO), the Comptroller/Chief Financial 
Officer, Operational Test and Evaluation (OT&E), and Deputy Chief Management 
Officer. In 2009, Congress believed that IT acquisition problems were beyond the 
scope of just the USD(AT&L) and that they were a problem of the scope of the 
Secretary of Defense (SECDEF) because many of the agencies that perform a 
function in the acquisition process do not report to the USD(AT&L) (FIASC, 
2009). Often, these offices are not aligned and according to Congress, it is 
unclear if these organizations are serving with common focus toward achieving 
improvements in the IT acquisition process (DSB, 2009). 


OSD Organizational Structure 

Principal Staff Assistants (PSAs) 



Figure 4. DoD Organization Chart (From “OSD Organizational 

Structure,” 2013, May 24) 
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The IT acquisition system is seen as a problem not just within the DoD, 
but also across the entire federal government because the same acquisition 
policy is applied throughout government. A 2008 GAO report found that nearly 
half of all major federal government IT projects were re-baselined, with half of 
those being re-baselined more than once, which, of course, adds more time to 
the acquisition process (GAO, 2008). 

Despite these significant acquisition problems, IT has been a great benefit 
to the Department and its military services and has changed business operations 
and the way warfare is conducted. However, the DoD has a ways to go in 
keeping pace with the Information Age as evident in all the problems that have 
been reviewed. All of the problems described throughout the literature contribute 
to the overall problem within the IT acquisition system—the failure to acquire IT 
systems in a timely manner. The problems are imbedded in many of the major 
processes used to acquire new technology. An extensive look at the traditional 
acquisition system and its processes will be described in Chapter III. This 
singular process has hampered IT acquisition with acquisition-related practices 
that favor large programs, high-level oversight, and a very deliberate, serial 
approach to development (NRG, 2010). Thus, the DoD recently began an IT 
acquisition reform effort and is currently fielding a new IT acquisition framework 
to address many of the problems discussed. Chapters III and IV will examine this 
new acquisition framework and its ability to provide the solutions to the IT 
acquisition problems described in this chapter. 
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III. REFORM EFFORTS AND THE CURRENT IT ACQUISITION 

SYSTEMS 


The problems identified in Chapter II have persisted for many years. For 
this reason, there have been many reform efforts initiated in order to address the 
various problems that have affected the overall acquisition system, not just IT 
acquisition. It is important to understand previous reform efforts because they 
provide a context with which to assess this newest reform effort and the 
probability that it will solve the problems identified. This chapter will begin with a 
brief history of the significant reform efforts that have taken place over the past 
30 years within the DoD acquisition system and how each reform effort has 
impacted the acquisition process, which has led to the current acquisition 
system. Then, this chapter will take an extensive look at the current acquisition 
system, which now consists of two separate strategies or frameworks: the 
traditional Defense Acquisition System framework and the new Business 
Capability Lifecycle (BCL) framework, which is exclusively designed for Defense 
business systems and major automated information systems (MAIS). 

A. ACQUISITION REFORM HISTORY: EARLY 1980s TO PRESENT 

The acquisition system has been problematic for a long time and the need 
to reform it has been widely acknowledged. Since the early 1980s, numerous 
studies have informed the DoD of the shortcomings of the acquisition system. 
Many of these studies have initiated changes to policy and process. Acquisition 
reform initiatives have occurred more often since the 1980s in large part due to 
information technology advancements in the commercial sector. 

In the early 1980s, acquisition reform was ushered in due to fraud, waste, 
and abuse issues found within the acquisition system (Allen & Eide, 2012). In 
response to these issues, a commission on Defense Management, referred to as 
the Blue Ribbon Commission, was instituted along with new legislation that 
included the Goldwater-Nichols DoD Reorganization Act of 1986 (Allen & Eide, 


47 



2012). The Blue Ribbon Commission reported that excellence in Defense 
management will not emerge simply by legislation or directive alone, but that the 
acquisition workforce must be empowered to succeed, and that DoD, the 
industrial base, and Congress must all set aside parochialism to restore a sense 
of shared purpose and mutual confidence (Allen & Eide, 2012). Furthermore, the 
commission recommended ways to improve program stability in order to mirror 
successful industry practices. Some of these recommendations were codified 
into law. In regard to DoD, the Blue Ribbon Commission found that diluted 
authority of execution existed within the Department, so a major restructuring 
ensued as a result of the Goldwater-Nichols Act (Allen & Eide, 2012). As a result, 
the National Defense Authorization Act for fiscal year 1987 directed that all 
acquisition functions be consolidated within the offices of the Service secretaries 
and that a newly created position of the Under Secretary of Defense for 
Acquisition be installed (Allen & Eide, 2012). 

During the 1990s, the Blue Ribbon Commission recommendations saw 
further reform introduced that impacted how the DoD viewed its workforce, how it 
conducted commercial practices, and how it did business. There existed a need 
to improve the quality of the acquisition workforce, even back then, so the 
Defense Acquisition Workforce Improvement Act (DAWIA) of 1990 was created. 
DAWIA established standards for education along with a specific career path for 
the acquisition workforce. One of the most significant reforms was initiated in 
1994 by then Secretary of Defense William Perry who directed the military 
departments to abandon military specifications and standards when contracting 
for goods and services (Allen & Eide, 2012). Instead, Perry mandated that the 
military departments use commercial specifications and standards. Also, Perry 
mandated the use of the Integrated Product and Process Development (IPPD) 
and Integrated Product Teams (IPTs) to manage program execution and that 
cost as an independent variable (CAIV) would be used to control cost growth 
(Allen & Eide, 2012). 


48 



Also in the 1990s, three other reform efforts took place: the Federal 
Acquisition Streamlining Act of 1994, the 1996 change to the Brooks Act of 1965, 
and the Clinger Cohen Act of 1996. The Federal Streamlining Act exempted 
procurement of commercial items from existing laws, which made them more 
prone to being used (Allen and Eide, 2012). To broaden its applicability, the 
Federal Streamlining Act also expanded the definition of “commercial product” to 
include many other items. In 1996, there was a significant change to the 1965 
Brooks Act regarding information technology. Until the mid-1990s, there was a 
separate set of processes and policies for acquisition of DoD IT systems, as 
called for in the Brooks Act of 1965 (NRG, 2010). In 1996, the IT and non-IT 
policies were merged because the requirements of the Brooks Act and other 
associated processes made the acquisition process too cumbersome and slow 
(NRC, 2010). Therefore, IT programs fell under a single acquisition process that 
was specified in the DoD 5000 series regulations. This reform effort was intended 
to provide a more flexible and nimble framework for all types of programs; 
however, not long after the IT programs were consolidated under DoD 5000, 
there developed a need to tailor the process to better suit the needs of IT 
programs. Since then, there has continued to be a need to tailor the process. 
Also, there have been repeated efforts to reform the process defined by the DoD 
5000 series in order to address persistent challenges in the IT acquisition 
system, which continue even today. Another significant event in the 1990s was 
the Clinger Cohen Act (CCA) of 1996, which was a landmark reform effort in 
regard to information technology. The CCA began as two separate initiatives, the 
Information Technology Management Reform Act (ITMRA) and the Federal 
Acquisition Reform Act (FARA). These two reform acts were eventually 
combined and were subsequently designated the Clinger Cohen Act after being 
signed into law as part of the National Defense Authorization Act for Fiscal Year 
1996 (CCA, 2006). The CCA also established the position of Chief Information 
Officers (CIO) in government agencies along with their roles and responsibilities 
(CCA, 2006). Furthermore, the CCA directed federal agencies to focus on the 
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results achieved through IT investments and a continuation of the streamlining of 
the federal IT acquisition process (Allen & Eide, 2012). The CCA also eliminated 
cost accounting standards that had discouraged the commercial industry from 
doing business with the government (Allen & Eide, 2012). Ultimately, the Federal 
Streamlining Act and the Clinger Cohen Act created a reduction in government 
red tape and allowed more commercial innovation, both of which were viewed as 
key enablers to improving acquisition outcomes. The 1990s would see one final 
reform in 1997 when then Secretary of Defense William Cohen instituted 
additional acquisition reforms under what was referred to as the Defense Reform 
Initiative (DRI). This initiative identified four pillars of reform: 1) a re-engineering 
to adopt commercial business practices, 2) a consolidation to streamline 
organizations to eliminate redundancy and maximize synergy, 3) more 
competition in the market to improve quality and reduce costs, and 4) elimination 
of excess support structures to free resources and focus on core competencies 
(Allen & Eide, 2012). Essentially, the 1990s offered a more business-minded 
approach to addressing acquisition issues and this approach carried over into the 
next century. 

The turn of the century came with revolutions in military affairs, as 
mentioned in Chapter II with concepts such as net-centric operations, which 
prompted further revolutions in the way the DoD conducted business. One of the 
central figures in ushering in these reforms at the turn of the century was then 
Under Secretary of Defense for Acquisition, Technology, and Logistics 
(USD[AT&L]) Jacques Gansler, who continues to influence the acquisition 
community today. In response to studies directed by Congress in the early 
2000s, Gansler sought a new direction through acquisition reform that included 
three goals: 1) reduce developmental cycle times for new weapons systems; 
2) reduce total costs; 3) and right-size the Defense Acquisition Workforce and 
infrastructure in the new business environment in order to realize savings 
through efficiencies and maximizing flexibility (Gansler, 2000). These efforts 
included training of the acquisition workforce on commercial practices, a focus on 
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cost and schedule over performance, and an increased reliance on an integrated 
civil-military industrial base (Allen & Eide, 2012). These efforts did not have an IT 
emphasis although they related to IT as well. Also during this time, then 
Secretary of Defense Donald Rumsfeld, with his own business-minded approach 
to transformation, thought buying the right thing was just as important as buying it 
right (Allen & Eide, 2012). Furthermore, Rumsfeld believed that network-centric 
capabilities were more important to future conflict than the traditional and ever¬ 
present legacy systems, which needed to be replaced (Adler, 2007). Riding the 
wave of the new Information Age, Rumsfeld worked to ensure that the DoD 
sought innovation from nontraditional defense industries that embraced 
technology capabilities. 

Leading up to the turn of the century, the acquisition strategy most often 
employed was the “waterfall” method for IT development. In the waterfall model, 
well-defined increments of information technology were designed, developed, 
and fielded in a pre-specified order in a waterfall or cascading process (NRG, 
2010). The waterfall model involved a specific and inflexible process that 
required documented specifications and a request for bids, followed by 
contracting, delivery, installation, and maintenance. Additionally, the waterfall 
method was document-intensive in order to satisfy the management goal of 
successfully meeting program objectives. One of the main disadvantages of the 
waterfall process was that it emphasized the acquisition process rather than the 
capability being acquired (NRG, 2010). The increments were sequential and any 
deviations called for a new baseline, which generally triggered a complete 
program review. These reviews were problematic because approvals at each 
step up the acquisition approval chain often became more difficult to obtain 
(DSB, 2009). The result was usually an increase in the time required to deliver an 
increment and the overall program (DSB, 2009). 

The waterfall acquisition model delivered acceptable results when 
developing and delivering technologies or requirements over a relatively long 
time frame; however, when that time frame needs to be shorter, such as is the 
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case for IT, the deliberate and sequential process of the waterfall model did not 
work well. As mentioned, IT resides in a domain where change occurs very often 
and in shorter time frames and the potential ability of adversaries to employ 
these new technologies quicker than the DoD is even more concerning. Reform 
was inevitable as the GAO concluded in its 2008 assessment. GAO 
recommended a fundamental change in the acquisition environment due to 
systemic problems not only with the process, which was viewed as not being 
agile enough to support current operations, but also in the requirements 
generation process (DSB, 2009). Others involved in the acquisition process, 
including Congress, made similar conclusions that the waterfall process was too 
document-intensive, time-consuming and process-oriented to be able to 
effectively respond to end-user requirements (HASC, 2010). Ultimately, this 
acquisition method was deemed inappropriate and a change was afoot via more 
reform. The DoD would eventually shift to an evolutionary acquisition method, 
which replaced the waterfall method, as described in DoDI 5000.02: 

Evolutionary acquisition is the preferred DoD strategy for rapid 
acquisition of mature technology for the user. An evolutionary 
approach delivers capability in increments, recognizing, up front, 
the need for future capability improvements. The objective is to 
balance needs and available capability with resources, and to put 
capability into the hands of the user quickly. The success of the 
strategy depends on phased definition of capability needs and 
system requirements, and the maturation of technologies that lead 
to disciplined development and production of systems that provide 
increasing capability over time. (USD[AT&L], 2008) 

Although the evolutionary approach is more conducive to IT acquisition, the 
approach did not solve all the problems and neither did DoDI 5000.02 because it 
still focused mainly on the procurement of weapons systems. 

Despite all the extensive acquisition reform efforts that began in the 
1980s, the DoD and Congress began to lose confidence in the acquisition 
system by 2005 and felt that the system was broken (Report by the Assessment 
Panel of the Defense Acquisition Performance Assessment Project, 2006). Upon 

this conclusion, the Defense Acquisition Performance Assessment (DAPA) 
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Project was established and in 2006 it conducted an integrated assessment of 
the entire acquisition process. One of DAPA’s major findings, like previous 
efforts, identified excessive oversight and complex acquisition processes as cost 
and schedule drivers (Allen & Eide, 2012). Also, DAPA cited that stability of 
requirements is essential for the acquisition system to be effective. In 2009, the 
Defense Science Board (DSB) took one of the first comprehensive looks at the 
DoD’s acquisition process as it relates to IT systems and found that it was simply 
too long and ineffective, and did not accommodate the rapid evolution of 
information technology (DSB, 2009). Furthermore, oversight ambiguity along with 
management issues were viewed as significant problems that needed to be 
addressed. Thus, the DSB recommended the development of a new acquisition 
and requirements development process for IT systems that would be agile and 
incremental, and allow requirements to be prioritized based on need and 
technical readiness (DSB, 2009). These DSB recommendations were eventually 
approved and implemented into policy. According to Gansler and Lucyshyn 
(2012), this act was certainly a step in the right direction because congressional 
oversight occasionally created ambiguities in the DoD’s acquisition process 
(Gansler & Lucyshyn, 2012). Moreover, Gansler and Lucyshyn stated: 

The Goldwater-Nichols Act, the Clinger Cohen Act, and the 2005, 

2007, and 2009 NDAAs lacked clarity with regard to specific 
features of their implementation. Rather than promoting innovation 
and flexible responses to acquisition problems, the ambiguities led 
to the creation of more structure, which, in turn, increased the 
amount of documentation. Although these congressional acts may 
have reduced systemic risk, they also prompted cost increases and 
programmatic delays. (Gansler & Lucyshyn, 2012) 

Essentially, Goldwater-Nichols, Clinger Cohen and the federal laws that ensued 
continued to complicate the IT acquisition process and caused overlapping 
responsibilities between the Linder Secretary of Defense for Acquisition, 
Technology, and Logistics (LISD[AT&L]), the Department’s CIO, and the Deputy 
Chief Management Officer. 
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The Obama administration initiated the most recent acquisition reform 
initiatives; however, some of which did not go far enough in terms of IT. For 
instance, the December 2008 revisions to DoD Instruction 5000.02 offered 
improvements to the process but did not address the fundamental challenges of 
acquiring information technology for its range of uses in the DoD. In 2009, former 
Secretary of Defense Robert Gates instituted his own vision of needed 
acquisition reform that was much like Rumsfeld’s affirmation that buying the right 
thing was as important as buying it right when he stated that “we must reform 
how and what we buy...meaning a fundamental overhaul of our approach to 
procurement acquisition and contracting” (Gates, 2009). Furthermore, Gates 
emphasized that significant change would be necessary to maintaining military 
superiority in an environment of ever shrinking economic resources and a 
reduced Defense budget. Gates identified three fundamental steps to reform: 

1) senior leaders must demonstrate commitment and courage to discontinue 
failing programs and programs that procure more capability than necessary, 

2) performance requirements must be scrutinized as necessary in order to avoid 
cost and schedule overruns, and 3) government program teams should be 
adequately staffed for proper oversight, cost estimates should be more realistic, 
and budgets should be protected for program stability (Allen and Eide, 2012). 

Finally, Congress passed the 2010 National Defense Authorization Act 
(NDAA) Section 804 in response to the Defense Science Board’s 2009 report 
concerning IT acquisition issues. Section 804 called for the development and 
implementation of a new acquisition process for IT systems, in particular Defense 
business systems (DBSs). The DoD released interim acquisition guidance for 
DBS that provided program managers with a transitional IT acquisition process 
until the new IT acquisition process could be developed and released (Bellomo, 
2011). The DoD would later release a report entitled A New Approach for 
Delivering Information Capabilities in the DoD, which provided an update on the 
progress towards development of the new IT acquisition process as well as some 
initial implementation guidelines. In 2010, then Under Secretary of Defense for 
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Acquisition, Technology, and Logistics (USD[AT&L]) Mr. Ashton Carter approved 
the use of the new Business Capability Lifecycle (BCL) process for acquiring 
DBSs as part of DoD’s implementation of the agile IT acquisition process 
(LISD[AT&L], 2013). However, this new IT acquisition system does not come 
without potential problems and shortfalls as will be explained in Chapter IV. 

Gates’ reform efforts, which were carried forward by his successor, former 
Secretary of Defense Leon Panetta and current Secretary Chuck Hagel, are 
continuing to play out today but beg the question if this latest attempt at 
acquisition reform will succeed where three decades of efforts have seemingly 
failed. The long history of acquisition reforms within the federal government and 
the DoD reflects that much has been done to identify the problems, implement 
solutions, and execute reform actions; however, most of these reform efforts 
appear to initiate a return to the conclusion that more reform is needed. There is 
a reason why many of the problems that have existed for years continue to 
persist. Furthermore, there is a reason why these change efforts did not work or 
resolve the problems. The history of reform efforts is an important backdrop to 
Chapter V topics because that chapter will offer insight into why these and many 
reforms efforts do not succeed or lead to effective change. For now, it is 
necessary to turn our attention to the current acquisition process and how it has 
been affected by these latest reform efforts. 

B. THE CURRENT IT ACQUISITION SYSTEMS 

1. Types of Major Automated Information Systems Acquisition 
and Acquisition Modeis 

Before discussing the current IT acquisition systems, it is important to 
understand the types of Defense business systems (DBSs) and/or major 
automated information systems (MAIS) acquisition goals the DoD seeks to 
accomplish. There are four general types of IT acquisitions: 1) application 
software development and integration, 2) commercial off-the-shelf (COTS) 
hardware and software integration, 3) integration of COTS and custom- 
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developed capabilities, and 4) commercially provided IT services (DSB, 2009). 
Another way of describing these four general types of IT acquisitions, as well as 
describing categories of DBSs is through the use of the terms DoD-unique 
systems, modified and integrated COTS, and software as a service (SaaS). 

DoD-unique systems, modified and integrated COTS, and software as a 
service (SaaS) encompass what the DoD seeks to procure in the IT acquisition 
process. A DoD-unique system is required when existing or modified commercial 
products cannot meet end-user requirements (Gansler & Lucyshyn, 2012). Thus, 
the DoD must develop its own unique product in an effort to fulfill end-user 
requirements. However, there is a downside to DoD-unique products in that a 
unique system or application generally requires a longer time commitment since 
the product is not available on the commercial market (Gansler & Lucyshyn, 
2012). DoD-unique systems are regarded as the least efficient way to acquire an 
IT system due to this downside. 

Commercial off-the-shelf (COTS) IT products are a worthwhile investment 
and offer the greatest benefit to the DoD although they cannot meet all the DoD’s 
requirements. COTS products are “as-is” systems and applications that can meet 
end-user requirements and do not require modification or integration of other 
components prior to implementation (Gansler & Lucyshyn, 2012). Using “as-is” 
COTS products allows the DoD to leverage commercial investments and take 
advantage of their technological innovation. By utilizing COTS products, the DoD 
significantly reduces research and developmental time, and takes advantage of 
industry best practices (Gansler & Lucyshyn, 2012). However, when it is 
essential for a COTS product to be integrated into an existing system, COTS 
products often require modification. Thus, commercial products that have been 
modified to meet DoD requirements are referred to as modified COTS products 
and like as-is COTS products, developmental time is reduced compared to DoD- 
unique systems. To further meet unique end-user requirements, it is often 
necessary to integrate both DoD-unique systems and COTS systems into an 
existing system. The integration of a COTS system as a component differs from 
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modified COTS because modified COTS are obviously modified while integration 
involves the use of a COTS system as a component within an integrated system 
(Gansler & Lucyshyn, 2012). 

Finally, software as a service (SaaS) is a software delivery method where 
the Internet or a cloud computing service provides the functionality or capability 
required. SaaS is beginning to become popular within the DoD as evident in the 
DoD’s 2011 release of the Cloud Computing Strategy. This strategy emphasizes 
cloud computing as a method to help agencies provide highly reliable, innovative 
services quickly, despite resource constraints (Kundra, 2011). 

As mentioned, DoD-unique systems, COTS products both modified and 
integrated, and SaaS are the types of IT acquisitions the Department currently 
seeks to acquire. In doing so, there are now two distinct processes that are used 
to acquire Defense business systems and/or major automated information 
systems (MAIS): the traditional Defense acquisition System and the Business 
Capability Lifecycle (BCL) model. As discussed in Chapter II, MAIS comprised of 
a range of IT systems that include command and control systems, 
communications systems, and Defense business systems (i.e., logistics and 
financial management systems). These systems are intended to provide the DoD 
with access to a wide range of information in order to effectively organize, plan, 
execute, and monitor Defense operations. All MAIS programs must utilize one of 
two acquisition frameworks. The first framework is the traditional Defense 
Acquisition System framework, which applies to all DoD IT acquisition programs 
except business system modernization programs that exceed $1 million in total 
costs as indicated in DoD 5000.02 (USD[AT&L], 2008). The second framework, 
the Business Capability Lifecycle (BCL), is relatively new as it was released in 
June 2011. This framework applies only to business system modernization 
programs with total costs exceeding $1 million (LISD[AT&L], 2013). 
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2. The Traditional Defense Acquisition System Framework 

The traditional Defense Acquisition System framework is outlined in DoD’s 
5000 Series publications, specifically DoDD 5000.01 and DoDI 5000.02. The 
Defense acquisition management system framework can be described as an 
overarching process that integrates three interdependent processes: 
requirements, budgets, and procurements (Gansler & Lucyshyn, 2012). These 
three interdependent processes work both independently and cooperatively in an 
effort to meet IT program objectives. All three can be described in the three major 
decision-support systems discussed in Chapter II; the Joint Capabilities 
Integration and Development System (JCIDS); the Defense Acquisition System; 
and the Planning, Programming, Budgeting and Execution (PPBE) process. The 
product or system requirements are defined by the JCIDS, which also provides 
acquisition program evaluation criteria. The PPBE process determines the 
budget and is used to allocate and manage financial resources. The procurement 
process is essentially the Defense acquisition management system or 
framework. This framework is the mechanism through which the Department 
develops products and systems. In theory, each of these three processes is 
designed to work in a coordinated, efficient, and cost-effective manner to deliver 
required capabilities to the DoD. 

The Defense acquisition management system framework provides the 
steps that Major Defense Acquisition Programs (MDAPs) must take as they are 
planned, designed, acquired, deployed, operated, and maintained (GAO, 2013). 
The framework consists of five program lifecycle phases and five related decision 
points as depicted in Figure 5. The five decision points include three milestone 
decisions at milestones A, B, and C, which indicate program progression or 
stage, and two other decisions that consist of the materiel development decision 
and the full deployment decision (GAO, 2013). The materiel development 
decision authorizes officials to conduct analyses to assess the potential solutions 
that can satisfy the program’s requirements, and the full deployment decision 
authorizes the system to be deployed to all relevant locations after limited fielding 
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has been complete (GAO, 2013). For programs that are required to use this 
framework, the milestone decision authority (MDA) will either be the Under 
Secretary of Defense for Acquisition, Technology, and Logistics (USD[AT&L]); 
the DoD component head; a component acquisition executive (CAE); or when 
authorized, a designee (GAO, 2013). 
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Figure 5. The Traditional Defense Acquisition Management System 

(From GAO, 2013) 


The Defense Acquisition Framework consists of the following phases as depicted 
in Figure 5: 

• Materiel Solution Analysis. The purpose of this phase is to assess 
the potential materiel solutions for a military need; to refine the 
initial system solution (concept); and to create a strategy for 
acquiring the solution. At the end of this phase, the program 
reaches Milestone A, where a decision is made as to whether or 
not the program will advance to the next phase. 

• Technology Development. During this phase, technologies are 
developed, matured, and tested in conjunction with the 
simultaneous refinement of user requirements. A decision is made 
at the end of this phase to authorize product development based on 
well-defined technology and a reasonable system design plan— 
referred to as Milestone B. An acquisition program baseline (APB) 
is first established at the Milestone B decision point. A program’s 
first APB contains the original lifecycle cost estimate, schedule 
estimate, and performance parameters that were approved for that 
program by the milestone decision authority. The first APB is 
established after the program has assessed the viability of various 
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technologies and refined user requirements to identify the most 
appropriate technology solution that demonstrates that it can meet 
users’ needs. By the completion of this phase, the program must 
have mature technology, approved requirements, full funding, an 
acquisition strategy, and the APB. Additionally, the type of contract 
that will be used to acquire the system must be specified. The 
Milestone B decision authorizes entry into the next phase. 

• Engineering and Manufacturing Development. The purpose of this 
phase is to develop and integrate the full system, make 
preparations for manufacturing, and demonstrate through 
developer testing that the system can function in its intended 
environment. A Milestone C decision is made at the end of this 
phase to authorize entry of the system into the production and 
deployment phase or into limited deployment or low-rate initial 
production (LRIP) in support of operational testing. 

• Production and Deployment. During this phase, the system is 
produced, operationally tested, and deployed. At this point, the 
system achieves an operational capability that satisfies the end- 
users needs, as verified through independent operational testing 
and evaluation, and is implemented at all applicable locations. 

• Operations and Support. This is the final phase. Program personnel 
ensure that the system is sustained in the most cost-effective 
manner over its lifecycle. (GAO, 2013) 

The traditional acquisition system framework is designed to translate 
mission needs or requirements into stable, affordable, and well-managed 
acquisition programs and has proven relatively successful at producing 
weapons systems and larger platforms (Gansler & Lucyshyn, 2012). Although 
this linear acquisition process is based on the development of hardware systems 
(e.g., weapons and aircraft), it was initially intended to accommodate the needs 
of all DoD programs to include IT (Gansler & Lucyshyn, 2012). However, the 
deficiencies of this overall process make this framework ill-suited for the 
development of IT-centric systems and Defense business systems. 

The traditional Defense Acquisition Systems framework has been 
described as a highly complex mechanism that is fragmented in its operations. 
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As it relates to IT under this framework, attempts to accelerate IT development 
cycles in order to keep pace with technical innovation only serve to amplify this 
fragmentation (Report by the Assessment Panel of the Defense Acquisition 
Performance Assessment Project, 2006). Not only is the framework fragmented, 
but also its phases do not conform well with information technology as it relates 
to commercial industry best practices or COTS products. For instance, the first 
phase in the acquisition process is Phase A, which is intended to mature 
technology; however, information technologies in the commercial sector are 
largely established and already mature so this action is not necessary (HASC, 
2010). The next phase. Phase B, is intended to prepare a program for 
production; however, information technologies are not produced in quantities 
while being developed (HASC, 2010). The final phase. Phase C, is the 
production phase, which is irrelevant because information technology, once 
again, is not produced in quantity (HASC, 2010). To exacerbate these milestone 
phase issues, the time between the start of a program’s analysis phase to 
Milestone B is on average 43 months or 14 months to complete the analysis of 
alternatives and 29 months to complete the economic analysis (DSB, 2009). 
Furthermore, it has taken on average 48 months to deliver useful functionality 
from the Milestone B decision, which has required 40 months for development 
with an additional 5-8 months for operational testing and evaluation (DSB, 2009). 

With this being the case, IT acquisition programs have suffered 
considerably. Take, for example, the nine DoD enterprise resource planning 
(ERP) programs, which are being acquired to replace over 500 legacy systems 
and will perform business-related tasks (e.g., accounting and supply chain 
management). According to a 2010 GAO report, “six of the nine [DoD] ERPs 
have experienced schedule delays ranging from 2 to 12 years and five have 
incurred cost increases ranging from $530 million to $2.4 billion” (GAO, 2010). 
One of the nine ERP is the Navy ERP, which has experienced a schedule delay 
of 2 years (GAO, 2010). The GAO produced another report in 2013 as directed 
by the National Defense Authorization Act (NDAA) for Fiscal Year 2012 which 
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mandated that GAO select and assess DoD MAIS programs annually through 
March 2018 (GAO, 2013). The GAO 2013 report stated: 

Of the 14 selected Department of Defense (DoD) major automated 
information system (MAIS) programs, 9 had stayed within their 
planned cost estimates, while 5 did not (with cost increases ranging 
from 3 to 578 percent); 5 programs remained on schedule, while 
9 experienced delays (ranging from 6 months to 10 years); and 
8 programs met their system performance targets, while 5 did not 
fully meet their targets, and 1 did not have system performance 
data available. Looking at these areas collectively, 3 programs 
stayed within their planned cost and schedule estimates and met 
their system performance targets, and 2 programs experienced 
shortcomings in all of the areas—cost, schedule, and performance. 

(GAO, 2013) 

The Navy ERP was one of the 14 MAIS programs selected for review, as the 
Navy ERP remained on GAO’s radar as a failing MAIS acquisition program. The 
failures of the traditional Defense acquisition system while being used to acquire 
the Navy ERP were significant in delaying its completion. 

The Navy ERP is currently being acquired using the traditional Defense 
Acquisition System framework. The procurement process began in 2003 and it is 
still in the acquisition process because it is not fully deployed as of yet as 
depicted in Figure 6. As of November 2012, the Navy ERP had been fully fielded 
to 108 locations and 72,000 users but the program has been working to stabilize 
the system in order to achieve full deployment, which is planned for August 2013 
(GAO, 2013). Once fully deployed, the Navy ERP is intended to replace 
segregated legacy systems with a single integrated software system (GAO, 
2013). This new system will provide an end-to-end supply chain solution for 
receiving, processing, and fulfilling requests for resources; will integrate financial 
management, workforce management, inventory management, and material 
operations; and will provide a rapid response to logistical needs of operating 
forces (GAO, 2013). 
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First acquisition program baseline as of August 2004 



Latest schedule as of September 2012 
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Figure 6. Navy ERP (From GAO, 2013) 


As mentioned, the Navy ERP experienced significant schedule slippage 
that exceeded the planned schedule by more than 2 years. Delays occurred as a 
result of several issues in the program involving requirements, testing, and 
system development. In regard to requirements, there was a change in 2009 to 
remove certain maintenance requirements from the ERP that were perhaps 
unnecessary. As discussed in Chapter II, when using the traditional Defense 
acquisition system, the requirements definition phase has been problematic. It 
appears that the Navy ERP had an issue with “small-r” requirements, which 
again are the more detailed requirements or information associated with specific 
user interfaces and utilities. It is not specified why the Navy ERP’s maintenance 
requirement was removed, but it is clear that issues involving requirements serve 
to lengthen the IT acquisition cycle. Another issue occurred in 2011 regarding 
testing, which was also problematic within the traditional framework. For 
instance, a substantial number of system deficiencies were identified during 
system development and initial testing of a supply solution, which resulted in the 
program failing to achieve its planned full deployment decision (GAO, 2013). As 
discussed in Chapter II, testing has been an issue in the IT acquisition process 
because it is often integrated too late during system development. Perhaps, if 
testing were conducted throughout the process, the issue regarding the supply 
solution would not have caused such a significant delay, if any. Also, final 
operational testing and evaluation for the Navy ERP was delayed from April 2012 
to January 2013 due to the need for additional time to mitigate system 

deficiencies (GAO, 2013). Once again, system deficiencies could have been 
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detected and mitigated a lot sooner if the acquisition process were 
accommodating to testing early and often. Lastly, other program delays were 
attributed to changes that were implemented based on lessons learned from an 
earlier deployment. 

Schedule slippages and delays in delivering IT systems have been the 
focus of this study but, as discussed earlier, schedule delays and the long 
acquisition timelines have adverse effects on both cost and performance. In 
regard to cost, the schedule slippages significantly affected the Navy ERP’s initial 
lifecycle cost estimate. In fact, program officials attributed the lifecycle cost 
increases to schedule slippages, an increase in demand for on-site support and 
stabilization activities during system deployments, and adding requirements to 
support business process reengineering and improved financial management 
information (GAO, 2013). In regard to performance, these schedule slippages 
can be loosely tied to performance as well. For example, the Navy ERP had only 
partially met its system performance measures because substantial system 
deficiencies remained. In December 2012, program officials reported that the 
performance measure that it did not meet may not be related to the Navy ERP 
system and that root causes would be further identified during the final 
operational testing and evaluation scheduled to begin in January 2013 (GAO, 
2013). Originally, the Navy ERP testing and evaluation phase was scheduled to 
begin in April 2012, nine months earlier, but due to schedule slippages it did not 
take place. If the schedule had been maintained to allow testing and evaluation 
to occur in April 2012, then the performance measure that was not met due to an 
unknown problem could have been investigated and resolved a lot sooner in 
order to deliver required performance. 

Overall, the 2013 GAO report highlights the significant problems among 
current MAIS programs and many of these problems are the same old problems 
that have plagued the entire IT acquisition process over the past decade. There 
have been a number of assessments conducted by many groups that have 
determined the inadequacy of this framework as it relates to IT acquisitions. 
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After the Defense Science Board (DSB) released its 2009 report indicating that 
“16 percent of all IT projects complete on time and on budget, 31 percent were 
cancelled before completion, 53 percent were late and over budget, and of those 
that were completed, the final product contained only 61 percent of the originally 
specified features 10 years ago,” the National Defense Authorization Act of 2010 
mandated the development and implementation of the new Business Capability 
Lifecycle (BCL) acquisition framework. 

3. Business Capability Lifecycle Framework 

The DoD’s goal is to acquire IT systems quickly and cost effectively; 
however, this goal has been rarely achieved due to the deliberate process of the 
DoD traditional acquisition system. Thus, the Business Capability Lifecycle 
framework was created via a business process reengineering (BPR) effort that 
was aimed at making improvements by elevating efficiency and effectiveness of 
the end-to-end acquisition business process. The Linder Secretary of Defense for 
Acquisition, Technology & Logistics (LISD[AT&L]) established the new BCL policy 
in Directive-Type Memorandum (DTM) 11-009, Acquisition Poiicy for Defense 
Business Systems, which sets guidance for the implementation of this new 
framework. Also, the Office of the Deputy Chief Management Officer (ODMCO) is 
integral to the implementation process, as this office leads integration and 
improvement efforts for all DoD business operations. The BCL framework was 
authorized for implementation in June 2011 and was last updated in January 
2013. BCL policy only applies to DBS modernization programs that incur a total 
cost over $1,000,000 dollars. For programs less than this amount or for programs 
that are non-DBS, the traditional acquisition system still applies. 

In general, the Business Capability Lifecycle (BCL) framework is an 
“overarching framework for the planning, design, acquisition, deployment, 
operations, maintenance, and modernization of Defense business systems” 
(LISD[AT&L], 2013). BCL facilitates rapid Defense business systems and major 
automated information systems acquisition and deployment by providing a 
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process that is exclusively tailored to the unique requirements of DBS and MAIS 
programs (USD[AT&L], 2013). BCL takes a holistic approach to IT acquisition 
that includes doctrine, organization, training, materiel, leadership and education, 
personnel, and facilities (DOTMLPF) in order to conduct a rigorous analysis of 
the requirements to enable rapid delivery of business capabilities to the 
warfighter in a compressed time frame (USD[AT&L], 2013). The BCL framework 
has been set as mandatory guidance in the DTM but will be incorporated into 
DoD Instruction (DoDI) 5000.02 later this year. Also, the framework is viewed as 
a guideline and tailoring that is consistent with statutes and sound business 
practices is encouraged (USD[AT&L], 2013). 

The DoD has instituted BCL with the expressed intent to address the 
unique challenges of IT acquisition, recognizing that the traditional acquisition 
system is not agile enough to meet the speed at which new IT capabilities are 
being produced in the commercial sector. BCL recognizes that technology rapidly 
evolves, and, consequently, BCL mandates rapid capability development. The 
BCL framework consolidates the requirements, investment, and acquisition 
processes under a single governance framework and provides an end-to-end 
process that is intended to be much different from the traditional acquisition 
system (LISD[AT&L], 2013). Furthermore, BCL provides tiered accountability 
while delegating authority and accountability for program outcomes and 
compliance down to the lowest appropriate levels, which has been a problem 
under the traditional system (LISD[AT&L], 2013). The BCL model is based on 
best commercial practices and is more outcome oriented. Ultimately, the BCL 
framework is designed to address the long-standing problems that have affected 
the timely delivery of IT business capabilities. Specifically, BCL addresses 
problems such as programs lacking well-defined, strategically linked 
requirements; the multiple review and governance bodies that are redundant, 
delays created by bureaucracy; and JCIDS and DoDI 5000.02 guidance and 
procedures which are primarily designed for major weapons systems acquisition 
that have taken more than 5 years on average. 
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The BCL process seeks to employ an incremental approach to IT 
acquisition that would begin with an approved business need that requires a 
materiel solution. Then, the approved materiel solution is divided into discrete, 
fully funded, and manageable increments in order to facilitate development and 
implementation of the DBS (USD[AT&L], 2013). Furthermore, these increments 
are developed, tested and evaluated, produced, deployed, and sustained to be 
useful and supportable capabilities in an operational environment. Also, there 
can be multiple releases within a single increment or multiple increments can be 
approved concurrently if funding, approved requirements, and the appropriate 
entrance and exit criteria have been met (USD[AT&L], 2013). The emphasis here 
is that delivery of IT capabilities within a single increment must be based on 
mature technologies and funding must be in place. Functional capabilities that 
are not supported by adequate cost estimates, mature technologies, or any other 
reason will be deferred to subsequent program increments (USD[AT&L], 2013). 

The BCL framework consists of seven lifecycle phases and five decision 
points—milestones A, B, and C, a materiel development decision, and a full 
deployment decision as depicted in Figure 7. Along with these decision points, 
there are seven developmental phases in the BCL framework, one of which is a 
completely new concept and is referred to as the Business Capability Definition, 
which occurs at the very beginning of a program. 
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Figure 7. Basic BCL Framework (From GAO, 2013) 
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Additionally, the BCL framework comprises three distinct stages; Business 
Capability Definition (BCD), Investment Management (IM), and Execution. The 
Execution stage consists of the remaining phases (e.g.. Prototyping Phase) or 
the actual acquisition portion of the BCL process. In total, the BCL framework 
consists of the following processes: 

• Business Capability Definition (BCD). The purpose of this phase is 
to analyze a perceived business problem or need, capability gap, or 
opportunity and to document the results in a Problem Statement to 
inform the Investment Review Board (IRB) Chair and MDA 
decisions. The activities performed and documentation required in 
the BCD phase shall be used in lieu of the Joint Capabilities 
Integration and Development System (JCIDS). 

• Investment Management (IM). The purpose of this phase is to 
assess potential materiel solutions and to satisfy the phase-specific 
entrance criteria designated by the MDA for the next milestone. The 
entrance criteria for this phase are an approved Problem 
Statement, Analysis of Alternatives (AoA) Study Guidance, and 
AoA Study Plan sent to the MDA. 

• Prototyping. The purpose of this phase is to demonstrate the 
capability of the software to meet business process requirements 
as outlined in the Business Case. Prototyping includes installing IT 
in a relevant environment to gain the knowledge necessary to refine 
user requirements and inform APB development. The entrance 
criteria for this phase are completion and submission of a Business 
Case reflecting the AoA results and the proposed materiel solution, 
a CAE-approved Program Charter, full funding for the Prototyping 
Phase as certified by the responsible IRB and approved by the 
Defense Business System Management Committee (DBSMC), and 
compliance with the MS A statutory and regulatory requirements. 

• Engineering Development. The purpose of this phase is to 
demonstrate that the materiel solution for the increment has been 
designed, configured, developed, and tested in a manner 
consistent with the approved Business Case and Program Charter, 
and that the materiel solution is ready for limited fielding and testing 
in an operational environment. The entrance criteria for this phase 
are the completion of the specified objectives for the prototyping 
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phase, if conducted; full funding of the program or program 
increment; submission of a draft APB and an updated Business 
Case and Program Charter; and compliance with the MS B 
statutory and regulatory requirements. 

• Limited Fielding Phase. The purpose of this phase is to limit risk by 
providing the capability to a limited number of users and testing it in 
an operational environment. Operational test and evaluation 
(OT&E) shall determine the operational effectiveness and suitability 
of the system. The entrance criteria for this phase are completion or 
satisfaction of the objectives of the Engineering Development 
Phase; the Functional Sponsor or end-user’s determination that the 
capability achieves the outcomes specified in the Business Case; 
and the program’s compliance with the statutory and regulatory 
requirements. 

• Full Deployment Phase. The purpose of this phase is to field an 
increment of capability for operational use in accordance with the 
Business Case. The entrance criteria for this phase are completion 
of Initial Operational Test & Evaluation (lOT&E) or other required 
testing; declaration of initial operational capability (IOC); and 
satisfaction of the DOTMLPF solution outlined in the Business 
Case. 

• Operations and Support (O&S). The purpose of this phase is to 
execute a support program that meets materiel readiness and 
operational support performance requirements and sustains the 
system in the most cost-effective manner over its total lifecycle. 
Planning for this phase shall begin prior to program initiation and 
shall be summarized in the Business Case. O&S has two major 
efforts: lifecycle sustainment and disposal. The entrance criteria for 
this phase are completion and submission of an approved Business 
Case, satisfaction of any conditions imposed by the MDA at the Full 
Deployment Decision (FDD), and the Functional Sponsor’s written 
declaration that the system has achieved FD, as defined in the 
Business Case. (USD[AT&L], 2013) 

To meet the demand of rapid development, the BCL is designed to 
execute programs quicker than has been the case using the traditional 
acquisition system. For instance, the BCL process is set up to allow no more 
than 12 months between the Materiel Development Decision (MDD) and MS A, 
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no more than 12 months between the initial contract and MS B, and no more 
than 18 months between contract or option award and the Full Deployment 
Decision (FDD) (GAO, 2013). The final decision will be the FDD, which will be 
made by the MDA authorizing an increment of the program to deploy for 
operational use. 

For DBS programs that are MAIS using the BCL incremental acquisition 
approach, all functional capabilities associated with each increment will reflect 
the Acquisition Program Baseline (APB) or cost, performance, and schedule 
goals and must be achievable within 5 years from when funds were first obligated 
(GAO, 2013). For all DBS that are not MAIS, these programs must achieve Initial 
Operating Capability (IOC) within a 5-year period from Milestone (MS) A (GAO, 
2013). Ultimately, the Milestone Decision Authority (MDA) will not grant a MS A 
decision if IOC cannot be achieved within 5 years; and in no event will a Full 
Deployment Decisions (FDD) occur later than 5 years from when program funds 
were first obligated. 

The first program to achieve an acquisition decision under the BCL 
framework was a struggling Air Force financial management program called 
Defense Enterprise Accounting and Management System (DEAMS) (Information 
Technology and Cyber Operations, 2013). As depicted in Figure 8, DEAMS was 
initiated in 2003 and development continues today. Due to issues in the 
acquisition process, which utilized the traditional acquisition framework, DEAMS 
transitioned to the BCL framework in February 2012 (GAO, 2013). DEAMS 
Increment 1 was the first IT developmental process to utilize the BCL framework 
and the development process is currently underway. Increment 1 was developed 
to provide 60 percent of the Air Force with the entire spectrum of financial 
management capabilities and is also intended to be a key component of the 
DoD’s plan for achieving fully auditable financial statements by 2017 as required 
by the National Defense Authorization Act for fiscal year 2010 (GAO, 2013). 
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First acquisition program baseline as of February 2012 
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Figure 8. Prior to Milestone B, the program was complying with the 
traditional acquisition framework. Following Milestone B in 
February 2012, the program began complying with the BCL model. 

(From GAO, 2013) 


Although the program had been struggling under the traditional acquisition 
system, in 2007 and 2010, the Air Force began demonstrating some capabilities 
provided by BEAMS (GAO, 2013). Flowever, due to schedule delays experienced 
in 2010, the program underwent a critical change. This critical change resulted in 
a restructuring of the development of the program from two major releases to 
four major releases. Also, in 2012 under the BCL framework, the BEAMS 
program was restructured for a second time to include six major releases that will 
be deployed incrementally beginning with Increment 1 (GAO, 2013). 

Since establishing its first acquisition program baseline (APB), BEAMS 
had not experienced a schedule delay; however, the program experienced a 
critical delay in establishing this first APB (GAO, 2013). Once again, the program 
began in 2003 and the first APB was not established until nearly a decade later in 
February 2012. Essentially, the acquisition process had been underway for 
almost 10 years before it developed a robust estimate for how long it was going 
to take to be developed and implemented (GAO, 2013). Some of the schedule 
delays were attributed to the complexity of reengineering business processes 
and design issues. Also, evolving requirements and testing issues served to 
delay the schedule, which, of course, have been identified problems within the 
traditional acquisition system. 
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Although the BCL framework was authorized for use in 2010, 
implementation of the framework has been slow as the DEAMS program is one 
of only a few programs currently using BCL. However, according to the Deputy 
Chief Management Officer (DCMO), Ms. Elizabeth McGrath, the DoD is in the 
process of transitioning several major IT programs to the BCL framework 
(Information Technology and Cyber Operations, 2013). Since the BCL framework 
is relatively new and implementation of this acquisition strategy has been slow, 
there is little to no data on the success rate or proof of concept. However, the 
potential benefits of BCL have been articulated and many within the DoD stand 
behind this new acquisition strategy, especially as it relates to DEAMS. 
According to the DCMO, “through the use of this [BCL] approach, DEAMS has 
integrated traditionally stove-piped processes and enabled tight integration 
between the functional sponsor [or end user] and the program office” (Information 
Technology and Cyber Operations, 2013). But, again, there is no conclusive 
evidence or data, as of yet, to suggest that the BCL framework will resolve the 
systemic problems that have caused major delays in acquiring IT systems within 
the DoD. With this being the case. Chapter IV will take a closer look at the BCL 
solution and that of others who have recommended solutions in order to assess 
the likelihood of success in fixing the DoD’s IT acquisition system. 
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IV. BUSINESS CAPABILITY LIFECYCLE: POTENTIAL 
BENEFITS, SHORTFALLS, PROBLEMS, AND OTHER 

SOLUTIONS 


A. POTENTIAL BENEFITS OF BCL 

The premise of BCL is to provide an acquisition process for information 
technology that is based on successful commercial practices for the rapid 
acquisition and continuous upgrade and improvement of IT capabilities. 
Furthermore, the process is designed to be agile in order to deliver meaningful 
increments of capability in a shorter time span, ideally 12-18 months or fewer 
(see Figure 9). 



From Contract/Option award 


Figure 9. BCL Iterative Incremental Process (From LISD[AT&L], 2013) 

There are several potential benefits of using the BCL framework. First, the 
BCL framework is tailored for business systems not for weapons platforms. Also, 
the framework is more business oriented and avoids issues such as 
implementing solutions without fully understanding business needs. Second, BCL 
consolidates traditional requirements, investment, and acquisition processes 
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under a single governance structure (e.g., Investment Review Board, or IRB). 
The establishment of the IRB addresses the oversight and governance issues 
that were experienced under the traditional acquisition system. Third, the BCL is 
a more agile and flexible process that can be tailored to specific needs. Fourth, 
there is a focus on implementation and not on documentation. BCL minimizes the 
paperwork that has served to slow down the IT acquisition process. BCL’s core 
documents are the Business Case and the Program Charter. The Business Case 
provides an integrated, executive-level justification for the recommended 
approach to solving the defined problem, while the Program Charter documents 
the managerial methods, responsibilities, and governance needed to successfully 
execute the program (Office of the Deputy Chief Management Office, 2012). 
Also, the Business Case is the only document used for the approval process. 
Essentially, these two documents integrate, summarize, and/or replace content 
that had been used under the traditional acquisition system for making executive- 
level decisions (BCL, 2012). Lastly, the BCL framework can potentially offer 
greater transparency and visibility, which will enable senior decision makers to 
affect outcomes (Office of the Deputy Chief Management Office, 2012). 

B. BCL SHORTFALLS, PROBLEMS, AND POTENTIAL PROBLEMS 

When the BCL framework was first introduced in June 2011, there was 
much optimism that significant improvements were on the way; however, this 
optimism quickly faded as efforts to further define this new IT acquisition process 
began to stall (Gilligan, 2012). Progress began to stall as the result of significant 
impacts on various DoD processes that were created by proposed funding 
changes or the lack thereof, program implementation, and a shift to a portfolio- 
based construct across requirements (Gilligan, 2012). As discussions on these 
issues created gridlock among many acquisition executives and stakeholders, 
other efforts to further define the BCL process were also stymied. To further 
exacerbate the situation, over the past 2 years, IT acquisition reform efforts have 
been less of a priority for the DoD due to fiscal concerns related to reductions in 

the Defense budget. Nevertheless, the DoD remains committed to the new BCL 
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process, as continual improvements in the IT acquisition process are planned in 
revisions to the DoD’s 5000 series acquisition directives (Gilligan, 2012). 

For now, the DTM continues to set guidance for the BCL and the 
acquisition of DBS programs. As stated in the BCL implementation guidance, the 
new BCL framework is a “first step” at streamlining the acquisition process for 
business systems (DoD, 2010). In fact, BCL is still considered to be within its 
pilot phase as it is still awaiting official indoctrination into DoDI 5000.02. More 
importantly, the BCL model is described as a mandatory guideline but tailoring 
consistent with statute and sound business practice is encouraged (USD[AT&L], 
2013). Like any framework, BCL is an imperfect model of reality, but it is useful in 
addressing many of the issues that exist within the IT acquisition system. 
Essentially, the problems addressed in Chapter II regarding the misapplication of 
the traditional acquisition framework to IT acquisition, legislative and oversight 
issues, and requirements, appear to be addressed in the new BCL framework, at 
least in theory because again, there is no data as of yet on the success of the 
process. 

Although certain problems are addressed, there still exist other problems, 
potential problems, and shortfalls within the BCL process. Due to BCL being an 
imperfect solution, as recommended tailoring implies, there remain issues 
regarding its limited application, the acquisition funding process, program testing 
and evaluation, and acquisition workforce concerns and management issues that 
need to be further addressed. Also, potential problems exist in the timelines 
offered by the BCL framework and the promise of a rapid acquisition process, 
which, again, has not been validated. Another potential issue exists in the 
structure or process of the BCL framework and its resemblance to the traditional 
acquisition framework. These issues will be further discussed in the next three 
sections. 
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1 . 


BCL Framework Similarities to the Traditional Acquisition 
Framework 


A potential problem in the BCL framework is that this new framework may 
not produce the improvements predicted because it is not remarkably different 
from the traditional acquisition framework. Fundamentally, the BCL was designed 
to be different from the traditional acquisition system, but compositionally it is 
very similar. For instance, there are seven lifecycle phases and five decision 
points (Milestones A, B, and C, a materiel development decision, and a full 
deployment decision) in the BCL process. Along with the five decision points, six 
of the seven developmental phases are consistent with or similar to the 
traditional Defense Acquisition System framework in regard to the traditional 
framework’s five phases. Moreover, one phase (production and deployment) in 
the traditional Defense acquisition system framework corresponds to two phases 
(limited fielding and full deployment) in the BCL framework (LISD[AT&L], 2013). 
The only significant differences between the two frameworks are the BCL’s 
Business Capability Definition phase at the start of a program and the multiple 
developmental iterations and their associated timelines. This similarity to the 
traditional framework begs the question whether the new framework will bring 
about significant changes or produce the same stagnation that has plagued IT 
acquisition in the past. With no progress data available thus far, it is too early to 
tell if this new framework will yield the predicted improvements in speed, cost, 
and effectiveness of the IT acquisition process. 

An argument can be made that the iterative incremental aspect of the BCL 
process will be the difference maker; however, this concept was not recently 
created but has been an aspect of evolutionary acquisition since its inception. 
Moreover, the iterative incremental development ideas, as well as the BCL 
tenets, are not new concepts but have been around for several years. The roots 
of iterative, incremental development (IID) methods can be traced back many 
years. For instance, in 2002 the Linder Secretary of Defense for Acquisition, 
Technology, and Logistics issued a memorandum setting forth a model based on 
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multiple delivered increments and multiple spiral cycles within each delivered 
increment (NRG, 2010). Furthermore, the basic framework for BCL was 
recommended in the 2009 Defense Science Board report. Although it was not 
named the “Business Capability Lifecycle,” the basic elements (i.e., iterative 
development) were included in the report as a recommendation for a new IT 
acquisition system. 

2. BCL’s Limited Appiication 

One BCL shortfall is that it is limited in its application. While the BCL 
process is applicable across the DoD IT Enterprise, the process does not apply 
to all categories of systems across the IT spectrum. In fact, the BCL process is 
applicable only to systems such as networked IT systems (e.g., command and 
control and business systems); however, IT hardware requiring unique 
development and requisite production decisions will not use the BCL process 
(Bellomo, 2011). In other words, IT projects employing the new BCL process will 
not design unique hardware or conduct technology development. In fact, IT 
projects requiring those activities will use the traditional DoD acquisition system 
in an effort to ensure that appropriate focus remains on designing and developing 
the unique hardware (Bellomo, 2011). Moreover, business system modernization 
programs meeting a certain criteria (i.e., total cost over $1,000,000) are required 
to use the BCL framework; however, for projects less than one million dollars, 
those projects will have to revert once again to the traditional acquisition system. 
Essentially, the BCL process does not apply to or attempt to solve IT acquisitions 
problems for all IT systems. 

3. BCL Timeline Concerns 

Another shortfall is that the BCL timelines, albeit incremental and shorter, 
are still too long when all increments are combined to complete a program in its 
entirety and deliver capabilities to the end users. As stated in the DTM, when a 
Major Automated Information System (MAIS) DBS employs the BCL or 
incremental approach, all functional capabilities associated with a given 
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increment must be achievable within 5 years from when funds were first 
obligated (DoD, 2010). Also, all DBS programs that are not MAIS must achieve 
Initial Operating Capability (IOC) within 5 years from Milestone A, which 
potentially means more time will be spent before capabilities are matured and 
into the hands of end users. The fact is that some IT projects are likely to take 
the full 5-year period based on project requirements or even due to the allowance 
of that specific amount of time. 

Five years is an inordinate amount of time for an IT program to reach IOC 
or to be provided to the end user, especially if a system needs to fulfill time- 
critical operational requirements. For instance, time-critical operational 
requirements are extremely important in regard to cyber security. Moreover, 
identifying an agile and adaptable acquisition process that can field new IT 
capabilities and services in relatively short and responsive time frames in order to 
counter or prevent cyber threats is a pressing issue for the U.S. Navy. The U.S. 
Navy’s Program Manager, Warfare (PMW) 130, an office in the Navy’s Program 
Executive Office for Command, Control, Communications, Computers, and 
Intelligence (C4I), is focused on rapidly fielding innovative IT capabilities in order 
to secure the cyber domain, assure end-to-end information, and enable decision 
superiority (Porche et al., 2012). According to a 2012 study conducted by the 
Research and Development (RAND) corporation, 

[PMW] requires an acquisition and fielding cycle that can deliver 
hardware security products within 12-18 months, software security 
products within six to 12 months, and incremental development for 
both hardware and software every three months. These time 
frames are far shorter than the traditional acquisition cycle time, 
which can be 36 months from concept approval to initial operational 
capability or eight to 10 years for full operational capability. (Porche 
et al., 2012) 

This statement is mostly in the context of the traditional acquisition 
system; however, it applies to the BCL process as well. According to PMW, the 
Navy would like to follow the BCL’s iterative and incremental development 
process, but it is apparent that the BCL offerings do not met the desired timelines 

78 



(i.e., incremental development for both hardware and software every three 
months) in order to address emerging cyber threats (Porche et al., 2012). 
Consequently, the 2012 RAND study sought to identify ways to accelerate or 
bypass the acquisition process in response to the unique demands of PMW 
information technology and cyber programs. Ultimately, RAND recommended a 
distinct acquisition system for emerging needs that could be handled through a 
separate process and budget (Porche et al., 2012). 

Another potential BCL timeline issue that can create delays and 
undermine the intent of the BCL process is a failure to strictly adhere to the 
iteration time-box or the deadline-driven approach to system development. As 
described in Chapter 12 of the Defense Acquisition University (DAU) website, the 
timelines for the phases of BCL must be taken into consideration during program 
planning, scoping, and Business Case development because any violations of 
these timelines require revalidation of the Business Case that can potentially 
slow down the delivery of capability to the user (DAU, 2012). Table 1 outlines 
BCL timelines that may be subject to delay if not strictly adhered to, whether it be 
for a legitimate reason or not. 


Decision Period 

Time Aiiotted 

Vateriei Deveiopment Decision (MDD) to Miiestone 
[MS) A 

12 months 

MS A to iOC* 

k/Vithin 5 years 

MS A to Fuii Depioyment Decision (FDD) 

Mthin 5 years (or if no MS A, from when the 
oreferred aitemative was seiected by the MDA) 

MS A (contract / option award) to MS 8 

12 months or less*** 

MP** (contract / opton award) to MS B 

12 months or less*** 

MS B (contract / option award) to FDD 

18 months or less*** 


Table 1. BCL Timelines (From “DBS-specific Criteria,” 2012, June 5) 
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Also, another timing issue involves the Business Capability Definition 
(BCD) Phase because there is no set time limit for this phase to be completed. 
As discussed in Chapter III, the BCD phase is conducted at the very beginning of 
the process and consists of an analysis of a perceived business problem or 
capability gap and is an important first step as the new framework relies heavily 
on this phase being done correctly. But also, the BCL timeline depends on the 
Business Definition Phase being done in an appropriate amount of time that is 
consistent with the goal of timely acquisition. 

Timing is key for the BCL process to work effectively and this process 
depends on the time-boxing or a deadline-driven approach. In using the time-box 
method, work items can slip from one iteration to the next, but iterations are 
completed according to schedule, thus affording the opportunity to quickly 
identify erroneous estimates of the time required to complete deliverables and 
ensuring continuous user input regarding priorities (NRC, 2010). Although 
identifying erroneous time estimates and receiving user feedback is of value, the 
fact is that when work items are allowed to slip from one iteration to the next 
iteration, so do capabilities. Also, according to the DTM, functional capabilities 
that are not supported by adequate cost estimates, mature technologies, or 
otherwise not ready will be deferred to subsequent program increments 
(USD[AT&L], 2013). This deference or allowing of work items to slip will 
inevitably create delays in capabilities being delivered to end users. 

There are plenty of advantages to the incremental development concept, 
which is considered a commercial best practice; however, one disadvantage or 
drawback is that the needed capability may not be acquired until much later in 
the process or maybe even acquired at the tail end, which is at the 5-year mark 
in the case of the BCL process. Essentially, the BCL incremental process solves 
the capability gap problem a little bit at a time or piecemeal, but when done over 
a 5-year period, it is not much different than a lengthy acquisition process solving 
the entire problem over the same time span, except for maybe users getting an 
opportunity to have some functionality in hand (e.g., prototypes). According to the 
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Deputy Chief Management Officer Elizabeth McGrath (2011) in a HASC 
committee on improving management and acquisition of IT in DoD, “[we will 
group] capabilities such that they are delivered in a spiral fashion and not try and 
solve the entire issue at the get-go” (Improving Management and Acquisition of 
Information Technology Systems in the Department of Defense, 2011). Solving 
part of the problem still leaves a problem that can potentially linger for years. 
Also, delivering some capability and then adding to it in future iterations in order 
to make a system more effective in the long run begs the question of whether this 
method will provide enough capability in a timely manner or when it is needed. 
The iterative incremental method is, indeed, a proven technique as it is a 
commercial best practice; however, the 5-year period provided to execute this 
process does not work well enough in every scenario, especially in the case of 
the U.S. Navy’s cyber threat requirements. 

Overall, the BCL process appears to continue to allow too much time to be 
spent acquiring a system considering that technology advances every 18 
months. It does not seem practical for the DoD to ever keep exact pace with the 
advancements in technology given its bureaucracy; however, given commercial 
industry practices, it is practical that the DoD can do better than what the BCL 
framework currently offers. In fact, there are other proposed solutions to the 
problems identified in Chapter II that will be discussed in the next section. 

C. OTHER SOLUTIONS AND FRAMEWORKS 

Various studies of the DoD’s IT acquisition process have been undertaken 
in the past few years in an effort to propose solutions to improve the overall 
effectiveness and efficiency of the IT acquisition process. Many of these studies 
propose models or frameworks that are designed to facilitate a more timely 
acquisition process. The following three frameworks, proposed by three separate 
entities, offer similar solutions similar to the BCL process; however, each one 
provides additional methodologies and detail that can produce shorter timelines. 


81 



1 . 


Two Models for IT Acquisition for Software and Hardware 
Deveiopment 


In November 2009, approximately 7 months after the Defense Science 
Board (DSB) released its report on the failures of the traditional IT acquisition 
system, the Defense Information Systems Agency (DISA) requested that the 
National Research Council (NRG) conduct an assessment of the efficacy of the 
DoD’s acquisition and test and evaluation (T&E) processes as applied to IT 
(NRG, 2010). In response, the NRG formed a committee of IT systems 
acquisition and T&E experts; commercial software developers, and software 
engineers, computer scientists, and other academic researchers that was tasked 
with the following: 

• Evaluate applicable legislative requirements 

• Examine the processes and capabilities of the commercial IT sector 

• Examine the DoD’s concepts for systems engineering and testing in 

virtual environments 

• Examine the DoD acquisition environment 

• Recommend how to improve the acquisition, systems engineering, 
and T&E processes to achieve the DoD’s network-centric goals. 
(NRG, 2010) 

To complete these tasks, the committee reviewed IT acquisition documents 
concerning the process, held briefings from commercial and military experts in IT 
systems acquisition, and held internal deliberations among committee members 
to determine issues and recommend solutions. Like the DSB report and many 
other studies that have recommended reforms to the Defense acquisition 
system’s processes and rules that govern the development, procurement, 
testing, and fielding of new capabilities, the committee concluded that there is a 
need for a unique acquisition process for IT (NRG, 2010). Furthermore, the 
committee reached the same fundamental conclusion of other studies but added 
another dimension in defining differing types of IT systems and suggested an 
acquisition process for each. Thus, one of the most significant recommendations 
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was the NRC’s proposal of two different acquisition methods, one for hardware 
and one for software acquisition. 

For software acquisition programs, the model is referred to as Software 
Development and Commercial off-the-shelf (COTS) Integration (SDCI) 
framework. SDCI was designed for IT programs that are focused on the 
development of new software to provide new functionality or to integrate 
commercial off-the-shelf (COTS) components (NRC, 2010). The hardware model 
is referred to as COTS hardware, software, and services (CHSS) framework. 
CHSS was designed for the acquisition of COTS IT hardware, software, or 
services to exploit commercially available products and services without 
modification to meet DoD needs, although modification to meet environmental 
requirements in a deployed environment can also be addressed in this category 
of programs (NRC, 2010). Both SDCI and CHSS programs are based in 
commercial best practices and are especially suitable for acquiring IT systems 
that support DoD information enterprise requirements (NRC, 2010). 

Within IT development, there are two basic types of IT developmental 
processes: hardware and software. Given their distinct nature, each requires 
different developmental processes. For instance in software, the number of lines 
of executable code is increasing drastically, which further exacerbate the 
challenges of IT development (HASC, 2010). Moreover, software projects are 
more difficult to manage than hardware projects for a few reasons: 1) software is 
not a tangible product or physical system whereas hardware is and you can 
see and measure the developmental process better than you can for software; 
2) in software projects, it may not be obvious until late in the project that the code 
is meeting or not meeting the requirements, whereas with hardware you will be 
able to tell sooner if not right away; and 3) unlike hardware projects, testing and 
integrating of software products is not simple and can yield more problems late in 
the project. 

In regard to CHSS or hardware components of IT programs, they are most 

heavily influenced by Moore’s law, which, again, predicts the doubling of capacity 
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per unit expenditure every 18 months, so obsolescence is a concern if hardware 
projects take years to develop (NRG, 2010). In contrast to hardware components 
of IT programs, the software components are most heavily influenced by the fast 
pace of technology change in the Internet environment and the difficulty at times 
to define requirements (NRG, 2010). In both types of IT developments, rapid 
change is a fundamental factor that must be addressed, and iterative, 
incremental development (IID) strategies are indeed appropriate ways to address 
this rapid change, especially when done quickly (NRG, 2010). However, the 
nature of the capability increments should differ for hardware and software 
components because of the different issues that drive them. Thus, the SDGI and 
GHSS frameworks were designed to capture these differences in their 
developmental approaches. Following are descriptions of the proposed program 
phases and decision milestones for both the SDGI and GHSS programs. 

Software Development and Gommercial off-the-shelf (GOTS) Integration (SDGI) 
programs consist of the following decisions and phases as shown in Figure 10: 

• Material Development Decision. The purpose of the Material 
Development Decision (MDD) is to validate the need for material 
development to address the requirement for a new or improved 
mission capability as a result of a projected deficiency or 
obsolescence in existing systems that cannot be addressed 
appropriately through continued evolution of those systems; a 
technological opportunity; or an opportunity to reduce operating 
cost. An additional purpose is to gain approval of a draft top-level 
(“big-R”) capability description and draft concept of operations 
(GONOPS) for the capability. 

• Business Gase Development. This phase enables leadership to 
make an informed, rational initial decision to invest in a program. It 
should further evolve the draft capability description and draft 
GONOPS and develop alternative approaches or system concepts 
for the proposed program. It should formalize the approach to 
quantify costs that will be incurred in the program and benefits 
expected to be achieved by the program, and conduct an analysis 
of the trade-offs among the alternatives to assess the anticipated 
costs and benefits of each in order to recommend a preferred 
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approach or system concept. It should also identify major risk 
factors that could jeopardize success and propose mitigation 
strategies for each major risk factor. In so doing, it should develop a 
proposed schedule and budget for the capability increments from 
the initial capability increment through to the final capability 
increment and anticipated lifecycle costs, and propose an allocation 
of the top-level requirements identified in the draft capability 
description to the capability increments. 

• Milestone A: Planning, Analysis, and Concept Demonstration 

Decision Phase. The purpose of this decision is to validate the 
business case and analysis of alternatives, and to authorize entry 
into the initial Planning, Analysis, and Concept Demonstration 
Phase. 

• Increment 1 Planning, Analysis, and Concept Demonstration 

Phase. The purpose of this phase is to provide further validation of 
the recommended alternative approach and its projected costs and 
benefits prior to formal initiation of the program. Also, this phase 
can use prototyping to demonstrate key features of the proposed 
solution. 

• Increment 2 Planning, Analysis, and Concept Demonstration 

Phase. The purpose of this phase is to allow for subsequent 
planning and analysis phases after the initial one leading to the 
initial Milestone B, Program Initiation Decision. 

• Milestone B; Program or Capability Increment Initiation Decision. 
The purpose of this decision is to validate the overall refined 
capability description and how big-R requirements are allocated 
across all subsequent increments, and the time-phased scope of 
deploying capability across the increments. It must also validate the 
proposed small-r refined requirements allocated to the next 
increment, together with the plan for how the increment will be 
executed. 

• System Development and Demonstration (SDD) Phase. The 
purpose of this phase is to develop the next increment of capability 
through a learning and communicating cycle of time-boxed 
iterations informed by the end-user’s perspective and integrated 
testing and evaluation as key components of the learning and 
communications process throughout the iterations. 
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• Milestone C: Capability Increment Deployment Decision. The 
purpose of this decision is to assess the risk versus benefit of 
deploying the capability developed during the SDD phase to the 
subset of end users within the intended deployment scope. This is 
a marked departure from the current approach of assessing 
whether a fixed set of requirements including key performance 
parameters (KPPs) has been achieved with cost and schedule 
floating to whatever level is necessary to achieve that objective. In 
this approach, the increment is time-boxed and executed with the 
cost and schedule constrained to the baseline set at the previous 
Milestone B decision and the degree of success in meeting the big- 
R requirements set for the increment. 

• Deployment Phase. The purpose of this phase is to deploy the 
developed capability to the intended subset of end users. If the 
capability developed during the SDD Phase and its deployment 
approach is straightforward, the Deployment Phase can be a very 
simple and straightforward activity. If, however, the capability is 
complex, and especially if there are interdependencies with other 
programs, complex installation procedures not suitable for “point- 
and-click” installation by the end user, and/or unique training 
requirements, significant planning and effort may be required to 
deploy the capability. 

• Operations and Sustainment Phase. The purpose of this phase is 
to support all previously deployed versions of a capability still in 
operational use. This support includes activities such as operating 
an end-user help desk and responding to problems encountered in 
operational use of the capability, including the development and 
distribution of patches and maintaining a configuration status 
accounting baseline for all installations of the capability (NRG, 
2010 ). 
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As depicted in Figure 11, COTS hardware, software, and services (CHSS) 
programs consist of the following decisions and phases which are the same or 
similar to SDCI with exceptions where indicated: 

• Material Development Decision. The purpose of this phase for 
CHSS is the same as for SDCI programs. 

• Business Case Development. The purpose of this phase for CHSS 
is the same as for SDCI programs, though with much greater 
emphasis placed on aligning the business strategy and investment 
strategy with the technical incremental capability strategy. 
Correspondingly, there should be much less emphasis on a 
concept of operations (CONORS) for purely unmodified COTS 
hardware, software, and services. 

• Milestone A: Planning, Analysis, and Concept Demonstration 
Decision Phase. These decisions for CHSS are conceptually similar 
to those for SDCI programs; however, the difference at this 
decision milestone and in the subsequent program phases is that 
concept demonstration should be undertaken if and only if there are 
clear issues or questions that must be resolved through 
demonstration that cannot be resolved in successive capability 
increments. This will frequently not be the case for the use of 
unmodified COTS products or services. As such, concept 
demonstration should be regarded as optional, with a bias to not 
performing it for most programs. The principal focus should be on 
the planning and analysis activities. 
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• Increment 1 Planning, Analysis, and Concept Demonstration 

Phase. The purpose of this phase for CHSS is similar to SDCI 
programs with the exception of the change in emphasis discussed 
in Milestone A for CHSS programs. Furthermore, requirements will 
typically focus on capability, capacity, and key nonfunctional 
requirements (e.g., operational availability and environmental 
qualification for hardware). 

• Increment 2 Planning, Analysis, and Concept Demonstration 

Phase. The purpose of this phase for CHSS is the same as that for 
the second increment in SDCI programs. However, for subsequent 
planning and analysis phases after the initial one leading to the 
initial Milestone B, Program Initiation Decision, and the process can 
be substantially abbreviated. 

• Milestone B: Program or Capability Increment Initiation Decision. 
The purpose of this decision is the same for CHSS as those for 
SDCI programs. 

• System Development and Demonstration (SDD) Phase. As with 
SDCI programs, the purpose of this phase for CHSS is to provide 
the next increment of capability. Since developmental efforts are 
not involved, the nature of the learning and communications cycle 
and the role of the end user and other stakeholders change, as 
does integrated testing and evaluation. Also, since the focus is on 
COTS software configuration, hardware integration, or hardware 
ruggedization to meet environmental qualification requirements, 
and not on software development, time-boxed iterations can still 
play a role but are not as critical as they are for SDCI programs. 

• Milestone C: Capability Increment Deployment Decision. The 
purpose of this decision is the same for CHSS as SDCI programs, 
with one addition: validating the attainment of an environmentally 
qualified first article for COTS hardware programs targeted at 
deployable units. As with SDCI programs, if there are subsequent 
increments, this Milestone C decision should ideally be conducted 
coincident with the Milestone B decision for the subsequent 
increment since many of the factors affecting the deployment 
decision can also materially affect the composition of the next 
increment. 
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• Deployment Phase. The purpose of this phase for CHSS is the 
same as it is for SDCI programs. 

• Operations and Sustainment Phase. The purpose of this phase is 
the same for CHSS programs as it is for SDCI programs (NRC, 
2010 ). 



Figure 11. CHSS Framework (From NRC, 2010) 


Like the BCL framework, SDCI and CHSS frameworks use phases and 
decision points that are structured within an IID format with time-boxed capability 
increments; however, SDCI and CHSS increments are planned in 4 to 8 week 
iterations and do not take longer than 12 to 18 months to deliver meaningful 
capability to end users as shown in Figures 10 and 11. Essentially, the NRC 
provides two formats for IT software and hardware development that can be 
completed much quicker than the time frame indicated for the BCL process 
mainly because SDCI and CHSS account for the differences in developmental 
types. Although BCL advertises “flexible and tailorable processes,” it does not go 
as far as breaking its framework down for the different types of developmental 
processes for IT. 

As is suggested in the BCL implementation guidance, tailoring of the BCL 
framework is welcomed (USD[AT&L], 2013). With that, tailoring to account for the 
different strategies needed to address the different needs of both hardware and 
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software development could potentially serve to expedite the BCL process which 
again, can take as long as 5 years. Essentially, the BCL acquisition process 
should incorporate the processes and timelines found in both SDCI and CHSS 
process models. Doing so has the potentially to better address the issues for the 
Navy’s cyber security IT needs and the associated speed needed to acquire 
certain technologies. 

In regard to the overall change recommendations to the IT acquisition 
process, the NRC’s models have similar attributes similar to the BCL framework 
which include an emphasis on shorter cycle times to deliver the best IT to the 
warfighter; streamlined processes for requirements definition, budgeting, 
operational testing, and oversight; and the decomposition of larger programs into 
smaller projects or increments that are delivered to the user in an evolutionary 
manner (NRC, 2010). NRC’s emphasis on shorter cycles include time-boxed 
incremental deliveries of usable capabilities and time-boxed iterations within 
each capability increment that are focused on nonfunctional requirements and on 
an architecture that is suited for the intended operating environment (NRC, 
2010). Furthermore, NRC’s streamlined process for requirements will focus on 
“big-R” requirements during early planning and performance of integrated testing, 
and evaluation will be commensurate with risk and benefit. The NRC’s 
employment of IID methods incorporates the voice of the end users as well as 
provides an acquisition governance process that empowers end users in the 
acquisition oversight decision processes (NRC, 2010). The decomposition of 
larger programs and decisions driven by risk and benefit will provide an 
incremental build-out of the architecture in scope and scale sufficient to meet the 
needs of the functional requirements of each capability increment (NRC, 2010). 
Ultimately, the NRC’s recommendation offers much of what BCL offers, except 
the timelines provided by the NRC frameworks implement capabilities much 
sooner. 
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2. Four Models for IT Acquisition for Software and Hardware 
Deveiopment 

In November 2009, around the same time as the NRC’s study, Acquisition 
Solutions Incorporated (ASI) conducted its own assessment of the IT acquisition 
problem within the DoD. ASI engaged with the Deputy Assistant Secretary of 
Defense for Command, Control, and Communications, Intelligence, Surveillance, 
and Reconnaissance and the DoD CIO to develop an alternative model for IT 
acquisition based on the DSB 2009 report (Gilligan et al., 2009). ASI focused on 
the concepts presented in the DSB report in order to develop an implementable 
acquisition process to quickly comply with the new congressional mandate and to 
achieve rapid delivery of information technology solutions that meet government 
users’ needs (Gilligan et al., 2009). AIS noted the following factors that influence 
IT acquisition processes: 

• The technology for information systems exhibits continuous and 
very rapid evolution 

• There are an increasing number of commercial off-the-shelf 
(COTS) components available 

• Users’ requirements for an information system evolve as users gain 
experience with early capabilities 

• Most IT systems or services are components of a larger “system of 
systems.” (Gilligan et al., 2009) 

Furthermore, ASI cited the differences in the types of IT developmental programs 
just as the NRC study had described. ASI also emphasized that these 
differences must be accommodated in the acquisition processes government 
organizations employ in order for the IT acquisition process to be effective 
(Gilligan et al., 2009). 

Ultimately, ASI developed a set of guidelines for the DoD to rapidly 
acquire new IT systems. These guidelines are built on industry best practices, 
lessons learned from both industry and government, and are tailored specifically 
for IT acquisitions. Also, the ASI model is built on agile development, test, and 

contracting methods to achieve rapid delivery of products (Gilligan et al., 2009). 
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Accordingly, ASI established six principles that underpin its proposed IT 
acquisition models: 

• Divide requirements for larger IT solutions into smaller projects. 

• Use acquisition “process templates” that recognize the differences 
among types of IT efforts. 

• Use CIO and acquisition governance authorities as well as end- 
user approval for key decisions in the IT acquisition process. 

• Employ standard IT “platforms” as the infrastructure target for newly 
fielded capabilities. 

• Provision and employ an enterprise-wide systems engineering, test, 
and integration capability. 

• Use portfolio management-like processes for project initiation and 
funds allocation. 

ASI’s Principle 1, dividing requirements, involves the same concept used 
in the BCL framework, which focuses on small, incremental projects to drive 
rapid fielding of user capabilities. Also, IT requirements are defined at a high 
level at the start of a project, with detailed requirements evolving throughout the 
project (Gilligan et al., 2009). ASI’s acquisition model uses small IT projects and 
interactively evolves the results of these smaller efforts into the larger system 
capability to deliver and field operational capabilities in 6-12 months (Gilligan et 
al., 2009). Additionally, through agile developmental methods, the IT project’s 
developer, the knowledgeable user, and the tester work together on each 
increment of capability which results in rapid delivery of useful capability and 
avoids surprises in the fielded system (Gilligan et al., 2009). Furthermore, as the 
increments of capability are fielded, continuous user feedback is used to tailor 
the requirements and priorities for successive increments. Essentially, smaller 
projects permit less overhead, less risk, and more rapid fielding, which helps to 
ensure that the program is meeting user needs. Much of this principle mirrors the 
BCL concept for requirements and smaller increments; however, the timeline 
intends to deliver capabilities quicker due in large part to Principle 2. 
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Principle 2, use of acquisition “process templates,” is similar to NRC’s 
recommendation of maintaining different process models based on the type of IT 
being acquired. Once again, BCL makes reference to being a “flexible and 
tailorable process,” but it does not go as far as explaining this flexibility and how 
its framework can be tailored. ASI noted that “as IT acquisition projects grow 
increasingly complex, the risks, acquisition activities, and oversight needs of 
individual programs grow more diverse” (Gilligan et al., 2009). Whether it is for a 
software product or COTS IT component acquisition program, there are 
inherently different risks and requirements to be met for each type. Therefore, it 
is necessary that the acquisition development and oversight process be tailored 
to meet the requirements of each type of acquisition. Thus, utilizing predefined 
acquisition process templates, each tailored for different types of IT projects, 
ensures that complex IT projects stay focused on those activities that are 
important for that particular IT acquisition type and increases the speed of the 
acquisition process (Gilligan et al., 2009). For a new IT acquisition model, and 
similar to what NRG recommended, ASI proposed four process templates that 
leverage best practices for four different types of IT acquisition programs and the 
inherent risks with each. The four templates identify the important acquisition 
activities needed to address specific risk areas; identify the key decisions points 
and the information needed to support the decision points; and define specific 
project planning activities, oversight decision points tied to risks, documentation 
needs, and decision event exit criteria (Gilligan et al., 2009). The four IT 
acquisition process templates are as follows: 


• Process Template 1: Application Software Development and 
Integration—for projects involving software development and 
software integration 

• Process Template 2: COTS Hardware/Software—for the purchase 
of non-modified commercial end items 
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• Process Template 3: Integrated COTS Capability—for projects 
requiring focused systems engineering to integrate a set of 
commercially provided hardware and/or software components 

• Process Template 4: Commercially Provided IT Services—for 
efforts to procure IT services. (Gilligan et al., 2009) 

Unlike BCL, acquisition process timelines for each of the four templates 
are measured in months, not years, which makes these models and ASI’s 
concepts even more appealing. Process Template 1 and 2 are very similar to the 
NRC’s Software Development and Commercial off-the-shelf Integration (SDCI) 
model and the COTS hardware, software, and services (CHSS) model in that 
they provide unique processes for acquiring these two different types of 
technologies. Although their processes and the names of their phases are 
different, they focus on the same areas and their associated timelines are 
similarly shorter than BCL. However, Process Templates 3 and 4 provide two 
different aspects of IT acquisitions. Figures 12 and 13 show the top-level 
diagrams of both Process Templates 3 and 4, respectively. The phases and 
decision points for these four process models are consistent with or similar to the 
phases and decision points found in the BCL framework and the NRC models. 
However, the most significant difference involves the quicker process timelines 
found in the four models. 
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Principle 3, use of CIOs, acquisition governance authorities, and end 
users for key decisions, is fundamental to ASI’s recommend new IT acquisition 
process. The governance process, which involves the CIO community, the 
acquisition community, and the user community, focuses on three key 
governance areas: requirements definition, oversight of program management 
processes, and management of the use of information technologies (Gilligan et 
al., 2009). Each of the three communities brings separate but essential 
authorities and accountability to the acquisition oversight process, “the 
acquisition community provides program management and contracting expertise; 
the CIO community provides IT architecture, interoperability, standards, and 
information assurance expertise; and the user community brings expertise and 
understanding of user needs and priorities” (Gilligan et al., 2009). Furthermore, 
qualified representatives from each community are given the authority to make 
timely decisions regarding cost, schedule, and performance as well as the 
responsibility to ensure full transparency of the project status (Gilligan et al., 
2009). Ultimately, this governance structure is vital to the proposed model and an 
effective IT acquisition system because “it helps to ensure that the right 
knowledge and authorities are available to make the decisions necessary to keep 
an IT project moving, to redirect it if needed, or to terminate a project when 
appropriate” (Gilligan et al., 2009). This principle, in comparison to BCL, is very 
similar to the governance restructuring found in BCL but the use of CIOs and the 
importance of effective management is given more emphasis. 

Principle 4, use of standard IT platforms, seeks to avoid the issue of DoD 
organizations selecting hardware and associated software that use a 
combination of commercially available technologies that are assembled and 
configured by different systems integrators and result in a large variety of 
distinctly different hardware and software platforms that must be properly 
configured, tested, and managed throughout the lifecycle (Gilligan et al., 2009). 
This method of acquiring IT is problematic and leads to delays because “each 
program specifies, purchases, and qualifies its own unique platform for security. 
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interoperability and stability; is expensive, with significant duplication and 
unnecessary effort; and complicates security efforts” (Gilligan et al., 2009). Thus, 
ASI’s new approach to IT acquisition provides direction on the mission-unique IT 
software or COTS capabilities by using standard prequalified IT platforms that 
implement DoD IT standards and necessary security, and can be provisioned 
quickly (Gilligan et al., 2009). Lastly, these standard platforms can be made 
available immediately, which will enable DoD IT projects to rapidly take 
advantage of the benefits of agile development methods and to rapidly field 
state-of-the-art COTS IT products. 

Principle 5, employment of an enterprise-wide test and integration 
capability, deals with the issue of government acquisition processes that often do 
not address IT integration and interoperability objectives until an IT project is 
already developed or in the process of being fielded. Thus, AIS emphasizes an 
organization-wide systems engineering process along with test and integration 
capabilities (TIC) to provide a way to ensure integration and interoperability of 
separately developed projects before fielding (Gilligan et al., 2009). Also, TIC 
provides a means to reduce project cost and schedule by eliminating the need for 
an individual IT project to maintain a separate and distinct test and evaluation 
facility (Gilligan et al., 2009). Additionally, TIC would be used to 1) conduct 
prototype evaluations or to demonstrate candidate technologies prior to a build or 
procurement decision, 2) test newly procured capabilities in a “system of 
systems” operational-like environment prior to fielding, and 3) ensure compliance 
and compatibility within established IT architectures and standards and other 
systems that exist within the target operational environments (Gilligan et al., 
2009). Essentially, TIC addresses many of the testing issues that were described 
in Chapter II by providing a single environment for developmental, operational, 
and security testing of newly developed IT capabilities. 

Principle 6, use of a portfolio management-like process for project 
initiation and funding allocation, is one of the most important principals because it 
addresses part of the funding issues. As discussed in Chapter II, acquiring 
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funding for IT projects, even high-priority projects, can take multiple years. Given 
the fact that IT advances a generation every 18 months and many mission-critical 
functions depend heavily on IT solutions, a rapid IT acquisition process requires 
an equally rapid funding process in order to be effective (Gilligan et al., 2009). 
Thus, ASI’s new models offer a portfolio management-like process for allocating 
funding within the execution year and permit trade-offs between competing 
needs that will lead to more effective use of IT funds (Gilligan et al., 2009). So 
rather than budgeting and managing the execution of funding tied to one specific 
project, the DoD can respond to advances in IT, emerging and urgent needs, and 
the progress within ongoing IT acquisition projects in a more rapid and flexible 
manner (Gilligan et al., 2009). This flexibility provides the means to be able to 
move funding around within the portfolio in order to support new requirements 
discovered during IT developmental processes. This funding process would be 
similar to the DoD’s use of working capital funds; in which funding for IT is 
allocated annually after examination of priority needs and project progress 
(Gilligan et al., 2009). Ultimately, this portfolio management-like approach 
eliminates the need to have full funding of the entire IT effort at project initiation 
in favor of incremental funding for each release (Gilligan et al., 2009). 
Unfortunately, the current PPBE process does not facilitate the ASI’s funding 
concept. Furthermore, this proposed change to acquisition funding methods are 
contingent upon congressional approval or action, which can be difficult. 

The six principles and four models proposed by ASI extend the concepts 
identified in the 2009 DSB report. Also, ASI concepts embody the best practices 
of industry as well as lessons learned from successes and failures within DoD IT 
acquisition. Through the implementation of ASI concepts, the DoD can achieve 
rapid acquisition of useful IT while providing needed and effective oversight. In 
comparison to the BCL process, ASI provides more granularity or emphasis in 
the areas of funding and the actual acquisition process given the four model or 
frameworks that account for different types of IT acquisition. Tailoring the BCL 
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process to account for the different process models and timely funding methods, 
as offered in the ASI models, can greatly decrease the acquisition timeline. 

3. IT 360 Solution 

Recognizing the unacceptably long IT acquisition process and the inherent 
problems within the entire system, former Under Secretary of Defense for 
Acquisition, Technology, and Logistics (USD[AT&L]) Jacques S. Gansler and 
William Lucyshyn, proposed an entirely new IT acquisition model in 2012. They 
developed a new IT acquisition process entitled “IT 360,” which is specifically 
tailored to meet the unique attributes of modern Defense business systems 
(Gansler & Lucyshyn, 2012). The label “IT 360” is a conceptual goal to mean that 
this process intends to complete one developmental cycle in approximately 360 
days or fewer (Gansler & Lucyshyn, 2012). Moreover, IT360 contains a series of 
initiatives that intends to enhance the speed and efficiency with which DoD 
acquires its IT systems. These initiatives are as follows: 

• Spiral development 

• Smaller, quicker to deliver, useful sets of capabilities 

• Rapid delivery 

• Greater use of COTS products 

• Aggressive use of prototypes and demonstrations 

• Continuous and integrated testing 

• Decentralized execution 

• Inclusion of end users 

• Enhanced competition (Gansler & Lucyshyn, 2012) 

These nine initiatives provide a means for the IT 360 process to deliver IT in a 
timely manner. The IT 360 process is based on the prevailing commercial model 
for developing software, which is the spiral development method or a cyclical 
approach to incrementally growing a system's capabilities while decreasing risk 
(Gansler & Lucyshyn, 2012). Also, spiral development facilitates large programs 
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being broken into smaller, agile increments that are responsive to innovation and 
allow for the rapid development of new capabilities. 

Rapid development and time-to-delivery are key objectives for every IT 
program, and IT 360 employs a scheduling concept that allows the traditional 
milestones and key decision points to be established early in the process and 
scheduled in much shorter periods (Gansler & Lucyshyn, 2012). For example, in 
IT 360, the time allocated to complete a business case and program 
implementation plan is short (approximately 30 days), unlike the undefined 
timeline for this phase in the BCL process. In an effort to maintain shorter 
timelines, IT 360 promotes greater use of COTS products that consist of proven 
capabilities (i.e., pre-tested and pre-certified) that can accelerate deliveries of 
capabilities within the established time frame (Gansler & Lucyshyn, 2012). With 
that, the IT 360 process encourages the use of prototypes that can be used to 
expedite source selection, reduce technical risk, and enable the selection of 
developers with a demonstrated ability to implement the required IT system for 
the end user. 

IT 360 has several other important factors that are beneficial to the IT 
acquisition process. For instance, IT development requires a continuous cycle of 
testing in order to detect security vulnerabilities and to avoid hyper-specified and 
unnecessary features (Gansler & Lucyshyn, 2012). Also, this continuous testing 
permits operational experience to inform future requirements that will ultimately 
ensure that IT systems are optimally suited to meet the needs of their intended 
users (Gansler & Lucyshyn, 2012). Additionally, IT 360 promotes decentralized 
execution and frequent product reviews. These methods alleviate the need for 
burdensome oversight and its’ associated documentation requirements while at 
the same time including users and other stakeholders throughout the process 
thus allowing program personnel and developers to better understand user 
requirements (Gansler & Lucyshyn, 2012). One other important factor is 
competition and IT 360 enables enhanced competition when new iterations are 
launched. Competition is an important component to effective acquisition 
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because it promotes efficiency and improved market performance by providing 
the defense industry with an incentive to develop better products quicker and at 
lower costs (Gansler & Lucyshyn, 2012). 

IT 360 utilizes both an evolutionary (or spiral) and an incremental 
developmental approach to IT acquisition (Gansler & Lucyshyn, 2012). 
Evolutionary development is an ongoing process of spiral development of system 
requirements, which are based on feedback loops from end users. Incremental 
development is essentially a process for implementing evolutionary acquisition 
yet there is a difference between evolutionary and incremental processes (Lorell, 
M. A., Lowell, J. F., & Younossi, O., 2006). In evolutionary development, the end- 
state requirements are not known in advance. This is an important conceptual 
distinction between evolutionary and incremental developments because unlike 
spiral or evolutionary development, the incremental development process 
assumes that the end-state requirements are known at the beginning of the 
developmental process. Thus, requirements can be known or unknown, and IT 
360 is designed to deal with both scenarios. In using both an evolutionary and 
incremental approach, the initial IT 360 product iteration may not possess all of 
the desired capabilities much like every other proposed incremental solution; 
however, the IT 360 process adds functionality to the system’s existing 
capabilities at a standardized, quick pace (Gansler & Lucyshyn, 2012). 

The IT 360 framework and process consists of seven phases that interact 
in a spiral fashion. These phases consist of Program Initiation; Increment 
Requirement Identification; Initial Increment Level Material Development 
Strategy; Architectural Alignment and Development; Development, 
Demonstration, and Oversight; Increment Capability Delivery, and Operations 
and Maintenance. The seven phases of the IT 360 process and their objectives 
and timelines are summarized as follows and are depicted in Figure 14: 
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• Program Initiation Phase. The initiation phase lays the foundation 
for program acquisition in four distinct ways. First, initial market 
surveys are conducted to generate potential solutions and establish 
a successful acquisition strategy. Using this strategy, the high-level 
requirements for the program are determined. These high-level 
requirements (i.e., “big-R” requirements) specify general system 
capabilities. Less emphasis is placed on minor requirements (the 
over-specification of which often leads to cost overruns and 
delays); rather, minor requirements are deferred to future 
increments. Next, both the high-level requirements and the market 
surveys are used to establish the overall procurement strategy, 
which will inform future phases over multiple iterations. Once the 
strategy is established, program-level and portfolio-level 
governance are then created and initiated. 

• Increment Requirement Identification Phase. During this phase, all 
potential solutions are considered, including COTS and other open- 
source solutions. With a total duration of approximately 30 days, 
the secondary goal of this phase is to ensure that capabilities are 
assigned to appropriate increments. By continuing the market 
surveys begun during the Program Initiation phase, program 
personnel work to ensure that the initial requirements meet as 
many user demands as possible, without front-loading onto early 
increments the more difficult, though perhaps nonessential, 
requirements. This is an important distinction over the traditional 
Defense acquisition system, which has a tendency to “waterfall” 
requirements, leading to increased rigidity throughout the process. 
This phase concludes with a material development decision (MDD). 

• Initial Increment Level Material Development Strategy. During this 
phase, a procurement strategy that is both product-specific and 
increment-specific is devised. While much of this strategy was 
developed during the previous phase, it is during Phase 3 that 
program personnel delineate a highly structured, comprehensive 
business case (i.e., program justification) and a fully developed 
acquisition plan and develop a mechanism that ensures 
coordination of stakeholder involvement. With an approximate 
duration of 30 days, this phase finalizes development and planning 
for the initial increment. The Initial Increment Level Material 
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Development Strategy phase is completed upon the approval of a 
request for proposals (RFP) by the Program Governance Board 
(PGB). 

• Architectural Alignment and Development Phase. After the release 
of an RFP to private-sector contractors, the Architectural Alignment 
and Development phase begins. This phase, which marks the 
beginning of system development, has a duration of approximately 
120 days. Once the architecture is determined, a risk assessment 
is conducted via prototyping and other methods. Once it is 
determined that the architecture carries sufficiently low risk. Phase 
4 concludes, which prompts the issuance of the capabilities 
development document (ODD) detailing why the system is needed; 
how it will be used; where the system will be located; who will need 
it; when it will be available; what the system is intended to do; how 
the system will be supported; and how much it will cost. Contracts 
are written to reflect the information contained in the CDD. 

• Development, Demonstration, and Oversight Phase. The issuance 
of a CDD marks the beginning of the Development, Demonstration, 
and Oversight phase, as well as the contract award. With an 
approximate duration of 180 days, it the longest phase of the IT 360 
process but also the most crucial. At this milestone, the decision 
authority approves the acquisition strategy; enterprise contracting 
and buying strategy; increment level detailed requirements; and 
market and spend analysis, acquisition program baseline, program 
implementation plan, test plan, and documentation. During this 
phase, the program manager will manage the development and 
demonstration of the proposed IT solution for a release of 
capabilities within specified cost, schedule, and performance 
parameters. Additionally, during this phase, multiple iterations of 
the system may be developed and tested (T&E is integrated into 
each iteration). Upon the release of each iteration, stakeholder 
input, oversight, and, if appropriate, corrective actions are 
combined to guide development of the next iteration. When 
successful, the program manager can rapidly deploy the capability 
or continue to demonstrate the capability in a live operational 
environment, depending on the nature of the program. 

• Increment Capability Delivery Phase. Assuming that the system 
fulfills the strategic, programmatic, and incremental requirements. 


103 



the PGB will authorize its entry into the Increment Capability 
Delivery phase. This phase has two main functions: full fielding and 
the transition to long-term operations and maintenance (O&M). The 
second function is the transition of the product to long-term O&M. 
This entails the creation or augmentation of a support structure 
specifically tailored to the capabilities of the newest product 
iteration. 




Operations and Maintenance Phase. The Operations and 
Maintenance phase oversees the creation or augmentation of a 
support structure specifically tailored to the capabilities of the 
released product. This entails complementary documentation and 
ongoing training in support of the recent release, refreshment of 
software, bug fixes, and administrative support. Entrance into this 
phase depends heavily on the user’s satisfaction with the solution 
and willingness to use the IT capability in the operational 
environment. The support plan is executed to meet the operational 
needs of the IT system in the most cost-effective manner. This plan 
will identify strategies to respond to discrepancies, failure reports, 
and hardware and software updates and upgrades. (Gansler & 
Lucyshyn, 2012). 
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Figure 14. The IT 360 Process (From Gansler & Lucyshyn, 2012). 
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Gansler and Lucyshyn’s IT 360 framework has four primary objectives: 

1) provide practical capabilities to the DoD enterprise quickly and efficiently, 

2) incorporate commercial management practices to reduce overall risk, 3) grant 
maximum flexibility to the Milestone Decision Authority (MDA) to reduce the 
reporting and administrative burden, and 4) respond effectively to the end-users’ 
needs. The IT 360 process removes many of the obstacles that have hindered IT 
acquisition; however, it will not remove all of the obstacles. Thus, Gansler and 
Lucyshyn identified several initiatives or actions needing to take place in order to 
support the IT 360 process and mitigate process shortfalls. These initiatives 
include document streamlining, flexible contracting mechanisms, and the 
implementation of forward-looking, technology-neutral standards. 

There are many similarities between IT 360 and BCL but there are also 
clear distinctions. For the acquisition of Defense business systems, each 
framework features smaller increments, continuous testing, and iterative 
prototyping to improve performance and increase efficiency in order to deliver 
capabilities. The differences between the two begin with their developmental 
process. The IT 360 developmental process is fundamentally different from the 
BCL process in its phases and approach within each phase. IT 360 appears less 
cumbersome and more efficient. Also, IT 360 employs a far more superior 
timeline in producing capabilities as it intends to deliver capabilities within a year 
while BCL is still within its Investment Management or its Prototyping phase 
within its first year. 
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V. CONCLUSION 


A. PERSISTING ISSUES FOR BCL OR ANY NEW IT ACQUISITION 

SOLUTION 

Gansler and Lucyshyn identified a number of challenges and barriers that 
must be overcome in order for IT 360 to be successful; however, these 
challenges and barriers are not exclusive to the IT 360 proposal but apply to 
every other solution proposed including the BCL process. Some of the most 
persistent challenges to timely IT acquisition include achieving commercial best 
practices (e.g., contracting practices), spending cuts, funding methods, workforce 
issues, and the inherent difficulty of implementing change (e.g., a new acquisition 
process). The barriers to timely IT acquisition consist of laws and regulations that 
were written by Congress to improve oversight within the Defense Acquisition 
System but have inadvertently created barriers. Furthermore, these barriers 
involve issues within research and development reporting, MAIS reporting 
thresholds, designated DoD authorities, and specified appropriations. 

1. Barriers 

Research and Development (R&D) reporting continues to require that all 
R&D funds used for programs be submitted to Congress at the beginning of the 
program to ensure that funding is accounted for and that oversight is adequate. 
This process is problematic given the evolutionary nature of BCL, IT 360, and 
other frameworks that use incremental development. Additionally, acquisition 
funding remains inflexible and cannot be applied throughout an IT acquisition 
portfolio. 

MAIS reporting thresholds create barriers because unlike non-MAIS 
programs, these programs are subject to more rigid reporting standards (Gansler 
& Lucyshyn, 2012). Since Defense business systems often meet MAIS cost 
thresholds. Defense business systems acquired using IT 360 and similar 
approaches may be subject to the MAIS reporting process, which can hinder 
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acquisition because it does not facilitate incremental development (Gansler & 
Lucyshyn, 2012). Portfolio-level reporting for MAIS Defense business systems 
should be implemented to resolve this issue. 

The designation of authority for all DoD acquisitions remains ambiguous 
even for the new BCL process. For instance, USD(AT&L) is responsible for the 
guidance and policy of the new BCL IT acquisition process; however, the DCMO 
is responsible for its implementation along with the DoD CIO who is responsible 
for agile, secure, efficient, and effective DoD IT (Porter, 2012). Another example 
is the authority of investment review boards (IRBs). The IRB’s ability to analyze 
the strength of an IT investments remains separate from the authority of the 
CIO’s responsibility to ensure product integration, which results in more 
ambiguity in oversight and decision-making authority (Gansler & Lucyshyn, 
2012). Essentially, oversight and responsibility may be applied inconsistently and 
can be detrimental to an IT acquisition program’s success. 

Lastly, appropriation methods for IT remain problematic. Under any of the 
proposed incremental developmental approaches, requirements may be added 
or changed after the budget is completed; however, this flexibility is jeopardized 
because of the appropriation methods and its requirement that all funds 
appropriated by Congress must be used only for the programs and purposes for 
which the appropriation was made (Gansler & Lucyshyn, 2012). This 
appropriations issue is one part of the overall funding issue that remains to be a 
challenge and will be discussed further in the next section. 

2. Challenges that Remain for Any IT Acquisition Solution 

a. Achieving Commerciai Best Practices 

The commercial industry has enjoyed great success in employing 
an agile IT acquisition approach. To deliver software and hardware capability 
more rapidly, the commercial industry has embraced the iterative, incremental 
development (IID) approach. The IID approach addresses two important issues 
for IT systems: the need for user interaction in setting requirements and the 
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complexity of development (NRG, 2010). Key attributes of the commercial IID 
approach include the prominence of the end-user’s involvement, a focus on 
requirements during early planning, the close integration of developmental and 
operational testing and evaluation into the development cycle, and the breaking 
down of projects into increments (NRG, 2010). Additionally, commercial IT 
market leaders manage IT demands by instituting standardization and discipline 
at the heart of their respective IT enterprises while enabling agile, customer-led 
innovation at the edge of these enterprises (NRG, 2010). In fact, most large IT 
providers have developed highly reliable, available, and scalable computing 
environments as pillars of their products and services provided. 

Many successful commercial IT providers have organized 
development around two key principles: portfolio management and development 
by small teams (NRG, 2010). Portfolio management is an effective method when 
limited resources impact IT acquisition because “limited resources are 
strategically allocated to a subset of possible projects where project risk, overall 
objectives, costs, benefits, and project interdependencies are all weighed, and a 
corporate-level decision is rendered on strategic investments” (NRG, 2010). 
Lastly, the greatest benefit of commercial industry practices is their timely 
development of IT products and services. Gommercial technology evolution 
cycles for communications, computers, and software average 18 months 
(Gilligan et al., 2009). For example, successful commercial practices are seen 
and utilized in companies such as Apple and Microsoft. These two industry 
leaders are able to produce products, both hardware and software, in an efficient 
and timely manner while meeting consumer requirements and demands. Their 
use of best commercial practices continues to set them up for success. 

The DoD desires an acquisition process that is modeled after 
“successful commercial practices for the rapid acquisition and continuous 
upgrade and improvement of IT capabilities” (DSB, 2009). Modeling successful 
commercial practices means that the DoD would be able to deliver meaningful 
capabilities that meet requirements in a more agile manner over a much shorter 
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period of time. Successful commercial practices are typically at the leading edge 
of innovation and technological advancements where DoD needs to take 
advantage; however, doing so remains a challenge for the DoD. For instance, 
even where the DoD attempts to adopt commercial practices, government 
contracting differs significantly from commercial best practices due to regulatory 
and legislative factors (e.g., fiscal constraints, transparency requirements, and 
the requirements for audit and oversight) (Gansler & Lucyshyn, 2012). As a 
result, contracting practices pose a challenge due to the inflexibility found in 
government contract procedures. 

In order for the DoD’s business systems to remain current as the 
pace of change in IT accelerates, greater contract flexibility is required. 
According to Gansler and Lucyshyn (2012), contracts must be structured to 
reflect evolving requirements and incremental developments and decisions 
(Gansler & Lucyshyn, 2012). For instance, program managers need to possess 
the level of authority to be flexible in order to be able to defer requirements to the 
next increment when necessary. However, DoD contracting practices generally 
do not provide program mangers with this level of flexibility (Gansler & Lucyshyn, 
2012 ). 


b. Acquisition Funding for incrementai Deveiopment 

A remaining challenge to achieving timely IT acquisition that limits 
the effectiveness of the BCL, IT 360, and other proposed incremental 
approaches, are IT acquisition funding procedures. As discussed in Chapter II, 
the source of the funding problem in IT acquisition is the DoD’s Planning, 
Programming, Budgeting, and Execution (PPBE) system. The PPBE system 
operates on a timeline that is inconsistent with the fast-paced IT commercial 
marketplace and offers no flexibility to be able to respond to the rapid changes in 
IT. For example, after Congress appropriates funding based on programs and 
appropriations, this allocation scheme becomes problematic when a program is 
allocated enough funding for development but later requires funding to support 
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additional testing. Under the current appropriations system, reallocation of funds 
among phases is impermissible and to exacerbate matters further, the budget 
component of the PPBE process requires a 3-year lead time (Gansler & 
Lucyshyn, 2012). Furthermore, IT programs are individually funded by separate 
appropriations with unique rules and definitions for each. This PPBE funding 
method continues to be an unresolved issue and will certainly impact any new IT 
acquisition process, including BCL. According to the DoD’s report to Congress in 
2010 regarding a new approach for delivering IT capabilities within the DoD, the 
DoD stated: 

In the new IT acquisition approach [BCL], a business case 
evaluation of alternatives, supported by appropriate BPR, will be 
conducted, and the materiel solution will be selected just prior to 
project initiation, ensuring that the latest technologies are 
considered. However, if the Department uses traditional Planning, 
Programming, Budgeting and Execution System (PPBE) processes 
to plan, program, and budget based on the approved business 
case, there will be a risk of incurring up to a two-year delayed 
project start. (DoD, 2010) 

With this being the case, the incremental processes of BCL, or of any other 
solution, is vulnerable to the same funding issues that have negatively impacted 
IT systems acquired using the traditional acquisition system. The prevailing 
guidance on the DoD’s newest approach, found in the DTM, does not address 
funding methods or this particular funding issue. 

The DoD has considered a few alternatives in the past in 
addressing this funding issue. These alternative approaches to addressing the 
funding issue include obtaining a single appropriation type for IT projects, 
establishing an IT revolving fund, and redefining a funding element that more 
accurately reflects the nature of IT capability investment (DoD, 2010). The 
alternative of obtaining a single appropriation type for IT projects would provide 
beneficial funding flexibility for development, procurement, and operations and 
maintenance and will also permit the funding of a range of potential IT materiel 
solutions (DoD, 2010). The alternative to establish an IT revolving fund to permit 
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incremental funding of alternatives to support the entire IT investment would also 
be beneficial; however, with this alternative, projects will need to be authorized 
through a series of internal controls (e.g., congressional notification) based on 
defined dollar thresholds of the planned procurement. Lastly, the alternative of 
redefining a funding element would provide the DoD with the necessary flexibility 
to realign funding to proposed projects with sound business cases (DoD, 2010). 
Of these considerations, obtaining a single appropriation type for IT and 
redefining a funding element would both be viable options; however, establishing 
an IT revolving fund with congressional control over the types of projects that can 
be funded makes this alternative less attractive and more cumbersome and 
subject to delays due to the congressional bureaucracy. Regardless of the 
funding alternative selected, the DoD has to request legislative action to change 
the current PPBE system in order to better facilitate BCL and rapid IT acquisition. 

c. Defense Spending Cuts and the Impact on Agile IT 
Acquisition 

Funding issues cannot be discussed without addressing the current 
Defense spending cuts as it relates to IT acquisition. Chief among the conceptual 
IT acquisition changes provided by all the proposed solutions and frameworks is 
the emphasis of an agile or incremental developmental process. The agile 
developmental process demands quick development of smaller pieces of a 
potentially larger program or large deliverables broken into constituent units that 
are then prototyped and tested far more quickly than if the entire program had 
been built before testing occurred (Porche et al., 2012). Implications of an agile 
approach and why it remains difficult to achieve relates to the current fiscal 
environment. 

Defense budget cuts will continue to impact the DoD’s plan to 
execute effective IT acquisition. In July 2013, Defense Secretary Chuck Hagel 
warned the Senate Armed Services Committee that automatic budget cuts have 
already negatively impacted DoD "severely damaging military readiness” 
(Philpott, 2013). Hagel went on to say that the Department "would seek to 
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minimize cuts in the day-to-day operating costs most closely related to training 
and readiness,” but without relief, Defense spending will take another $52 billion 
hit in fiscal year 2014. Readiness is most associated with planning for and 
acquiring assets for mission needs, which directly relates to all of the DoD’s 
acquisition activities including personnel. Defense budgets cuts are especially 
concerning for the agile acquisition concept and new process implementation 
due to what would be required in regards to funding to make it all possible. If 
agile IT is desired, then additional people, materials, and money are going to be 
required to make numerous IT acquisition actions happen along program 
lifecycles, which includes development, engineering, testing, security, and 
accreditation among other things. Furthermore, in this day and age of 
sequestration and shrinking Defense budgets, it is getting increasingly more 
difficult for the DoD to provide agile IT acquisition when resources are not 
available. Lastly, the DoD’s current motto is “doing more without more” as been 
expressed by Frank Kendall in the DoD’s Better Buying Power Memorandum 
(OUSD[AT&L], 2012). Essentially, this motto means doing more with less, but it 
appears infeasible to cut cost and attempt to improve a process that requires 
increasingly more funding. Due to the DoD’s enormous IT appetite, acquisition 
executives and senior leaders in the Department need to reconcile the dilemma 
between cutting cost and acquiring IT as rapidly as possible. 

There is an axiom in government acquisition regarding cost, 
schedule, and performance whereby an end user only gets to choose two of 
these three factors, for example cost and schedule, where the cost is implied to 
be lower and the schedule is implied to be more timely. Flowever, choosing both 
cost and schedule will put performance at risk, for if an end user gets the product 
cheap and fast, it may not be good, according to the axiom. Whether this axiom 
is true or not, the point here is that the DoD desires agile IT, and to acquire IT 
systems fast, it will definitely cost more money and the required performance 
may or may not be available depending on the stage of the incremental 
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development approach. Thus, funding remains to be a significant issue for BCL 
and any other framework to be effective and the DoD has to resolve this matter. 

d. The Acquisition Workforce and Acquisition Management 

One of the most important aspects to achieving effective IT 
acquisition involves the quality and quantity of the acquisition workforce. Quality 
equates to the experience, knowledge, and management ability of the workforce. 
In regard to quantity, the acquisition workforce has been significantly reduced 
over the past 20 years, which has resulted in a reduction in the DoD’s internal 
technical competencies (Gansler & Lucyshyn, 2012). Furthermore, over 60 
percent of the government IT acquisition workforce is older than 45 years of age, 
and many workers lack the specialized IT skills found in the younger generation 
(Gansler & Lucyshyn, 2012). Ultimately, the workforce and management issues 
addressed in Chapter II have not been resolved in their entirety within any of the 
proposed solutions including the BCL process, for no plan specifically addresses 
workforce improvements and its alignment with a new acquisition process. 

The 2009 DSB task force believed that improvements in four 
specific areas would ultimately improve the acquisition of IT in DoD: acquisition 
policies and process, roles and responsibilities of the CIO, milestone decision 
authority roles and responsibilities, and acquisition leadership and expertise 
(DSB, 2009). Of these four areas, the acquisition leadership within the workforce 
is key and more must be done to improve this critical element of IT acquisition. 
Regardless of any new acquisition concept or theory implemented, it is the 
people who are the drivers of success and the acquisition process is only an 
enabler. In other words, a new acquisition process alone will not result in success 
if matters involving acquisition expertise, leadership, and management (including 
change management) are not appropriately addressed. Without this crucial 
element, any new process proposed will potentially meet resistance and failure. 

As discussed in Chapter II, workforce problems involve a lack of 
appropriately trained, educated, and experienced acquisition personnel along 
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with a bureaucratic and cumbersome acquisition process. Also, stability in 
leadership, both civilian and military, remains an issue. For example, a 2013 
GAO study reported that an Air Force program experienced unstable leadership 
due to having four different program managers within a 4-year period (GAO, 
2013). Additionally, there is a growing concern due to budget cuts, hiring freezes, 
sequestration, and commercial sector competition that the DoD will not be able to 
hire and maintain highly qualified and experienced IT acquisition personnel. For 
example, in a 2013 HASC hearing on IT, General Keith B. Alexander, 
commander of United States Cyber Command, stated: 

The issue is they [the acquisition workforce] have taken a pay cut 
and now we are saying, “Well, you might get a pay cut again and 
this pay cut will be furlough and we are not sure how that is going 
to go, or where that is going to be.” That uncertainty is something 
that truly complicates their willingness to stay with us [DODj...these 
are technically qualified people. You go out to Google, they are 
looking for people today. You know, I sat down with the Google FIR 
[human relations] folks. They said, “Look, we are paying, you know, 
probably twice as much as you are paying folks” and they are 
having trouble getting them. (Information Technology and Cyber 
Operations, 2013) 

Although workforce issues have not been directly addressed in 
acquisition process improvements, there have been recent initiatives that have 
systematically addressed workforce concerns. First, former DoD CIO Vivek 
Kundra’s 25 Point Implementation Plan to Reform Federal Information 
Technology Management highlighted the role of the IT acquisition workforce, 
created focus on IT acquisition specialists, and helped in the creation of a new 
occupational category termed the “IT Program Manager” (Kundra, 2010). 
Second, the current DoD CIO, Teresa Takai, who is the IT acquisition workforce 
Functional Leader (ITFL), is now directly responsible for the IT acquisition 
workforce and in 2012 she issued the IT Acquisition Workforce Strategic Plan. 
This plan implements near-term initiatives and plans for longer-term objectives 
associated with DoD's IT Acquisition reform movement (Takai, 2012). Specific 
actions within this plan can be summarized under four guiding strategic goals: 


115 



• Create robust, sustainable IT acquisition and IT program 
management communities. 

• Develop a competency model and career roadmaps for IT 
acquisition and IT program management personnel. 

• Sustain learning and growth throughout the professional lifecycle. 

• Work across broad stakeholder communities to integrate IT 
acquisition reforms into IT acquisition curricula. (Takai, 2012) 

Since 2012, the ITFL has been engaged in improvement efforts 
with a preliminary focus on what is considered to be the "ABC's" of 
improvements: analysis of the existing state of the IT acquisition workforce; 
building the IT Functional Integrated Process Team (FIPT), and initiating a full- 
scale competencies review (Takai, 2012). The ITFL improvement efforts are 
ongoing and are potentially promising. In particular, issues of tenure and rotation 
of key acquisition personnel are discussed in the plan; however, it does not go as 
far to set policy or recommend actions as it relates to tenure and rotation. 

Although training and education are mentioned in the IT Acquisition 
Workforce Strategic Plan and are very important to the acquisition workforce, 
training and education are no substitute for experience in successfully managing 
acquisition programs of increasing complexity. Thus, acquisition personnel, to 
including uniformed personnel in certain capacities within the acquisition 
workforce, need a robust process of assigning and sustaining these key positions 
for the long term. This strategic plan strengthens and broadens those initiatives, 
but it falls short in resolving program instability and maintaining an experienced 
acquisition workforce. Also, the plan fails to provide change management 
direction for the workforce. Along with experience and good management, there 
needs to be change management initiative. 
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e. Organizational Change Management 

One final aspect of IT acquisition reform as it relates to a new 
acquisition process and the workforce involves organizational change 
management. No plan or solution proposed discussed a change management 
process or how the DoD will go about executing transformation to implement a 
new IT acquisition process. Change management is of such great importance 
that if not done successfully it is highly likely that the result will be a failure to 
implement the necessary changes in order to affect timely IT acquisition. As it 
relates to the acquisition process and the workforce, there needs to be an 
imperative to implement a change management plan that would facilitate the 
implementation of any new acquisition process as well as IT workforce change 
initiatives found in the workforce strategic plan. 

Given the size and complexity of the DoD, accomplishing change 
can be a very difficult undertaking, which is why effective change management is 
necessary. One of the most difficult aspects of change in implementing a new 
acquisition process is changing the culture because the workforce has become 
very accustomed to using the ineffective but well understood traditional 
acquisition system (Gilligan et al., 2009). In Leading Change: Why 
Transformation Efforts Fait, John P. Kotter (1996) postulated what he considered 
to be the primary reasons why change efforts fail. Kotter offered eight reasons 
why this failure occurs: 

• Not establishing a great enough sense of urgency 

• Not creating a powerful enough guiding coalition 

• Lacking a vision 

• Under communicating the vision by a factor of ten 

• Not removing obstacles to the new vision 

• Not systematically planning for and creating short-term wins 

• Declaring victory too soon 

• Not anchoring changes in the corporation’s culture (Kotter, 1996) 
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Of these eight reasons, the DoD has fallen short in at least two 
areas: not removing obstacles to the new vision (e.g., removing funding issues) 
and not anchoring change in the corporation’s culture or, in the DoD’s case, the 
organization’s culture. In regard to culture change, and closely related to Kotter’s 
postulates, there is the seminal work of Edgar H. Schein in his 1992 publication 
Organizational Culture and Leadership. In reference to organizational culture, 
Schein (1992) emphasized that behavioral or culture change is important to 
successful transformation (Schein, 1992). As described by the National Research 
Council (NRG) in Achieving Effective Acquisition of Information Technology in the 
Department of Defense: 

Cultural aspects of the DOD acquisition process that have an 
impact on the potential success of IT acquisition efforts include the 
following: the bias that larger is better, the sense that oversight 
personnel have no accountability for delaying needed IT 
capabilities, an emphasis on process risk (executing the acquisition 
process correctly) rather than on the risk of late delivery of end-user 
capability, an unwillingness to admit program failure, an emphasis 
on process over product, a belief that the DOD is genuinely unique, 
and the belief that what is good for large weapons systems should 
be good enough for IT systems. (NRC, 2010) 

It is clear that a culture change is necessary to usher in the sort of wide-ranging 
changes proposed by any new acquisition process. Both Kotter’s and Schein’s 
works provide a framework for assessing whether the DoD’s current IT 
acquisition reforms will be successful and by all accounts at this point, success is 
uncertain. To provide more certainty, effective acquisition leadership and 
management to include change management is absolutely essential. According 
to Allen and Eide (2012), “the prognosis for effective reform is dim without 
embedding leadership actions and institutional processes that will drive change 
in the culture of Defense acquisition. Without such intentionality, one can expect 
to repeat the history of unfulfilled mandates for reform” (Allen & Eide, 2012). 
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B. SUMMARY, FINDINGS, RECOMMENDATIONS, AND FUTURE WORK 

1. Summary 

Information technology (IT) has become ubiquitous and absolutely 
essential to the DoD and to United States national defense. Concepts and 
strategies such as network-centric operations, information superiority or 
dominance, and cyber security are integral to the DoD’s ability to conduct warfare 
in the twenty-first century. Furthermore, the DoD’s reliance on IT will only 
increase in the coming years and will continue to be driven by innovation and 
technological advancements. For these reasons, it is important for the DoD to 
resolve its IT acquisition issues. 

The traditional Defense acquisition system has failed in meeting IT goals 
in producing new technologies that conform to desired cost, schedule, and 
performance parameters. This study focused on the timeliness or scheduling 
portion of the IT acquisition process, although cost and performance are 
important factors that are influenced by schedule. Many government reports, 
congressional documents, academic papers, and other writings have concluded 
that the traditional acquisition process is ill-suited to efficiently deliver IT systems 
in a timely manner. This literature cited numerous IT acquisition deficiencies with 
regard to process, system or product development, workforce, and management 
of IT projects. Currently, improvements to the IT acquisition process are being 
made as part of an ongoing revision to DoD’s 5000 series acquisition directives 
and the implementation of the BCL framework for Defense business systems. 

With the initiation of the BCL framework in June 2011, the DoD has 
articulated its commitment to improving the acquisition process; however, 
implementation of BCL has been slow and uneventful thus far. Also, it is too early 
to determine if this latest reform effort will yield significant improvements in the 
speed and effectiveness of IT acquisition. Ultimately, the BCL effort may join a 
long line of acquisition reform efforts that have taken place over the past three 
decades in which many of these reform efforts have lead to even more reform. 
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This may occur because the BCL framework contains shortfalls and problems 
that will require further reform or tailoring. Although the BCL framework has 
potential benefits and confidence is high that it is the long-awaited solution to the 
DoD’s acquisition concerns, there is no data that can ensure optimism going 
forward. However, data does exist that suggests BCL, as well as any other 
proposed IT acquisition strategy, will continue to face problems. For instance, the 
BCL process maintains similarities to the traditional system in terms of process. 
Also, the process can take up to 5 years to develop an IT system to initial 
operating capability (IOC), which is a long time for an IT project to reach this 
point as compared to the commercial industry. 

Although the BCL process has replaced the traditional acquisition system 
for Defense business systems, there is much more work to be done due to 
lingering issues carried over from the traditional acquisition system. These issues 
involve achieving commercial industry best practices, which is a challenge given 
the DoD’s bureaucracy, regulatory procedures and statutes. Also, the IT 
acquisition funding process is not aligned to support agile acquisition methods 
and potential Defense spending cuts will only exacerbate this issue. Most 
importantly, the acquisition workforce and management of the acquisition 
process (e.g., MAIS reporting thresholds, designated DoD authorities, and 
change management efforts) need to be further addressed. The next two 
sections present a list of findings and recommendations based on this study. 

2. Findings 

• Finding 1: Different IT acquisitions (i.e., hardware or software) have 
inherently different acquisition process needs and thus necessitate 
different approaches or strategies to better accommodate timely 
acquisition. Essentially, the BCL framework may run the risk of 
going back to the one-size-fits-all approach if different processes or 
templates are not designated. 
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• Finding 2: Challenges and barriers to timely IT acquisition remain, 
which include achieving commercial best practices, Defense 
spending cuts, IT funding methods, and workforce and 
management issues. Barriers to the implementation of a new 
acquisition process involve issues within research and development 
reporting, MAIS reporting thresholds, designated DoD authorities, 
and specified appropriations. 

• Finding 3; The BCL framework has shortfalls, inherent weaknesses, 
and potential problems involving its similarities to the traditional 
acquisition process, limited applicability, and process timelines. 

• Finding 4: Funding processes remain a root issue for BCL that will 
limit its effectiveness. Also, there exists a dilemma between cutting 
cost and acquiring IT systems through agile means. No proposed 
solution, (i.e., BCL or IT 360) will be unaffected by shrinking 
Defense budgets and the DoD concept of “doing more without 
more.” 

• Finding 5: The DoD is likely to experience problems in full-scale 
implementation of the BCL process with its planned shorter 
durations and agile intent due to cultural comfort with IT projects 
taking multiple years along with the common practice of thorough 
implementation of DoD 5000 process steps. Essentially, these 
steps can negatively influence acquisition programs and cause 
them to lean towards larger increments and less timely delivery. 

• Finding 6: IT acquisition contracting procedures are not aligned with 
the objective of 12-month incremental deliveries, as outlined by 
BCL guidance and thus can serve to increase timelines. 

3. Recommendations 

• Recommendation 1: As was suggested in the BCL implementation 
guidance, tailoring of the BCL framework is welcomed. Due to 
shortfalls and potential problems identified within the BCL 
framework, tailoring should account for the different strategies 
needed to address the different needs of both hardware and 
software development projects which can potentially serve to 
expedite the IT acquisition process. Aspects of IT 360, along with 
the concepts of process templates and shorter timelines from other 
process models or frameworks, should be incorporated into BCL. 
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• Recommendation 2: The DoD must submit to Congress a proposal 
for changes to be made to the PPBE funding mechanism to make 
the IT funding process more flexible and adaptable to meet the 
requirements of different IT acquisition programs. Furthermore, it is 
recommended that IT funding be aligned to meeting portfolio 
management efforts or allocated to mission areas rather than 
specific programs. Essentially, more stable funding to ensure 
efficiency and sustainability is highly recommended. 

• Recommendation 3: The DoD recently established annual reporting 
on Defense Acquisition (e.g., programs, institutions, workforce, 
managers, executives, and industrial partners) with its first report 
released in June 2013, which focused primarily on performance 
related to Major Defense Acquisition Programs (MDAP). Due to the 
need of progress data or measures of effectiveness on the BCL 
acquisition process, it is recommended that the next DoD annual 
report on the performance of the Defense acquisition system focus 
exclusively on the BCL process. This data and analysis could then 
be used to measure performance to inform future decisions on 
programs, policies, processes, or recommend further tailoring. 

• Recommendation 4: Along the same lines as Recommendation 3 in 
regard to assessment, it is recommended that the DoD evaluate 
appropriate metrics for BCL progress reporting in an effort to fine- 
tune the process using lessons learned from the initial 
implementations. 

• Recommendation 5: It is recommended that DoD programs that 
require rapid acquisition, particularly those involved with cyber 
security, work to ensure stable sources of funding. In the interim, it 
is recommended that the DoD explore all available funding options 
to include rapid contracting options. 

• Recommendation 6: Because agile acquisition reflects such a 
significant departure from past IT acquisition processes, it is 
recommended that training of both government and industry 
personnel be given a higher priority with an emphasis on culture 
and organizational change for government employees. Additionally, 
it is recommended that a change management plan be executed 
simultaneously with BCL implementation and that this plan be 
incorporated in the updated version of DoDI 5000.02. 
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• Recommendation 7: Effective IT acquisition process 
implementation management, change management, and overall 
acquisition system management are key. Therefore, it is 
recommended that the DoD focus on the IT acquisition workforce 
and its management of the IT acquisition system. 

• Recommendation 8: It is recommended that the DoD mandate 
fielding of IT projects at the same pace or near same pace as the 
commercial industry with a penalty of project cancellation to provide 
the incentive to overcome resistance to change and other 
problems. This mandate can also serve to align other critical 
processes (i.e. oversight, development, testing, and contracting) in 
order to ensure that they function on the same expedited timeline. 

• Recommendation 9: Given all the IT acquisition change proposals 
over the past several years, it is recommended that the DoD focus 
its efforts on the barriers and challenges to any new process 
tailored for IT acquisition and prioritize reform efforts to quickly 
implement changes. In particular, it is recommended that the DoD 
initially focuses on three actions; 1) the mandate that IT projects 
deliver usable capability in durations—shorter than what is 
proposed in BCL (i.e., 6 to 12 months); 2) submit funding change 
proposals to Congress and, in the interim, the DoD should adapt 
contracting processes to make them more agile; and 3) incorporate 
acquisition templates into the BCL framework in order to expedite 
the process. 

4. Future Work 

Future work and research within the area of IT acquisition should consist 
of the following activities: 

• Conduct an assessment of the feasibility to tailor the BCL 
framework to incorporate process templates to account for different 
types of IT acquisition processes 

• Adapt BCL to meet the needs of all IT acquisition programs (e.g.. 
National Security Systems, and Warfighting Systems), not just 
Defense business systems 

• Develop a change management plan for the new acquisition 
process 
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• Conduct an analysis of the programs currently using the BCL 
framework to gain insights into the underlying effects of BCL 
process; doing so will inform better policy and programmatic 
decisions. 

C. CONCLUSION 

As the DoD continues its efforts at transformation of its military forces and 
Defense business systems in order to meet the various challenges of twenty-first 
century warfare, it will increasingly rely on IT systems, despite budget cuts. Thus, 
DoD will need to resolve its IT acquisition issues in order to provide systems in a 
timely manner that meet requirements and are within budget. The DoD has 
introduced a number of initiatives in the last decade in an effort to improve IT 
acquisition; however, problems remain. BCL, despite having many potential 
benefits, does not go far enough to address the underlying conditions and 
obstacles discussed throughout this study. Improvements to requirements 
gathering and oversight have seemingly been addressed in the BCL framework 
although issues involving the acquisition workforce, acquisition management (i.e. 
change management), and allocation of funding continue to persist. Most 
importantly, how can any program succeed that can take up to 5 years to 
complete? With an 18-month technology change cycle in the commercial sector, 
lengths of time such as this significantly reduce the potential for the successful 
implementation of an information system that will meet end-user requirements. 

Despite the current implementation of a comprehensive restructuring of 
DoD IT acquisition, the process is not entirely fixed. Given the current DoD 
budgetary environment and the increased pressure to reduce Defense spending, 
the DoD must find a way to continue to improve the efficiency with which it 
develops, acquires, and fields IT systems. There is no silver bullet to fixing IT 
acquisition, as the proposed recommendations within this study are only ideas; 
however, effective management up and down the chain has to be a focal point. 
Acquisition personnel, both civilian and uniform, are the drivers of success; the 
acquisition process is only an enabler but the process has to be accommodating 
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to timely acquisition. Addressing funding impediments, installing effective 
acquisition management, and incorporating aspects from other frameworks (e.g., 
templates and associated timelines) into the BCL framework along with an 
organizational change management plan, can have a positive impact on the 
speed and effectiveness of IT acquisition within the DoD. 

There is no claim that all the findings and recommendations presented 
here are entirely new ideas; however, they provide new focus in addressing this 
matter. The bottom line is that the inability to effectively acquire IT systems in a 
timely manner is detrimental to national defense. These problems must be 
overcome because IT is critical to DoD’s capabilities for they provide command 
and control, decision support, and overall situational awareness. The challenges 
surrounding IT acquisition must be addressed systematically in order to improve 
the acquisition process. As mentioned in the Defense Science Board 2009 
report, “without an acquisition process that accommodates, and takes advantage 
of, IT’s rapid pace of change, future DoD acquisition officials will likely be 
frustrated in their efforts to equip the nation’s warfighters and weapons systems 
with the needed information technologies” (DSB, 2009). DoD needs to focus its 
efforts by mandating that IT projects deliver usable capability in shorter durations 
(e.g., 6-12 months) by modifying the BCL process to include acquisition 
templates and their associated timelines; fixing the funding process to make it 
more agile; and improving acquisition workforce and overall acquisition 
management. Doing so, will increase the DoD’s likelihood of delivering IT 
capabilities expeditiously. 
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